B3. Build, Buy oder Partner
Der Bezugsweg eines Anwendungsfalls, also selbst bauen, ein Standardprodukt kaufen oder mit einem Partner umsetzen, entscheidet über Geschwindigkeit, Kosten, Abhängigkeit und Datenhoheit.
Was dieses Kapitel liefert: die Entscheidungskriterien-Matrix für die Wahl des Bezugswegs und den Anbieter-Fragenkatalog mit elf Kategorien für die strukturierte Auswahl. Den Rahmen setzt die Grundsatzentscheidung aus Kapitel B1, ob Kompetenzen intern aufgebaut oder zugekauft werden; hier wird sie je Anwendungsfall konkret. Die Schnellregel aus Kapitel B2 (Differenzierung selbst bauen, Standardfunktion kaufen, Lücken mit Partnern überbrücken) wird dazu zu einer belastbaren Entscheidung ausgebaut.
Vorlage: Entscheidungskriterien-Matrix
Jedes Kriterium wird auf einer Skala von 1 bis 5 bewertet. Die Tabelle erklärt, was das Kriterium konkret bedeutet, woran hohe und niedrige Werte erkennbar sind und wohin ein hoher Wert tendiert.
| Kriterium | Was gemeint ist | Beispiel für hohen Wert (5) | Beispiel für niedrigen Wert (1) | Tendenz bei hohem Wert |
|---|---|---|---|---|
| Differenzierung | Erzeugt der Anwendungsfall einen Vorteil, den Wettbewerber nicht einfach nachkaufen können? „Abheben" heißt: Der Fall beruht auf etwas Eigenem, meist exklusiven Daten oder einzigartigem Prozesswissen. | Betrugserkennung auf Basis der eigenen zwanzigjährigen Schadenhistorie | Chatbot, der Öffnungszeiten und Lieferstatus beantwortet | Selbst bauen |
| Datensensitivität | Wie hoch ist der Schutzbedarf der verarbeiteten Daten? Je sensibler, desto größer das Risiko, sie einem Dritten anzuvertrauen. | Gesundheitsdaten, Bonitätsdaten, Betriebsgeheimnisse | Öffentlich verfügbare Produktkataloge | Selbst bauen |
| Verfügbarkeit am Markt | Existiert bereits eine ausgereifte Standardlösung, die das Problem nachweislich löst? Ein gelöstes Problem erneut zu bauen, ist verschwendetes Budget. | Texterkennung (OCR), Transkription, Übersetzung | Branchenspezifische Nischenaufgabe ohne Produktangebot | Kaufen (bei hoher Verfügbarkeit) |
| Interne Kompetenz | Ist die nötige Fachkompetenz im Haus vorhanden oder realistisch aufbaubar? Ohne eigenes Können wird ein Eigenbau zur Dauerbaustelle. | Eingespieltes Data-Science-Team mit Produktivbetrieb-Erfahrung | Keine einzige Person mit ML-Erfahrung | Selbst bauen (nur bei hoher Kompetenz) |
| Zeitdruck | Wie schnell muss die Lösung stehen? Eigenbau dauert typischerweise 6 bis 18 Monate, ein Kaufprodukt ist oft in Wochen einsatzbereit. | Wettbewerber ist bereits live, Kund:innen fordern die Funktion | Interne Optimierung ohne Termindruck | Kaufen oder Partner |
| Regulatorische Komplexität | Wie hoch ist der Compliance-Aufwand, etwa bei Hochrisiko-Einstufung (siehe Kapitel B8)? Ein erfahrener Partner kann Dokumentations- und Nachweispflichten mittragen. | Hochrisiko-Anwendung nach Annex III mit Konformitätsbewertung | Internes Werkzeug mit minimalem Risiko | Partner mit Regulatorik-Erfahrung |
| Integrationstiefe | Wie eng muss die Lösung in Kernsysteme (ERP, CRM, Bestandssysteme) eingebunden sein? Tiefe Integration ist mit Standardprodukten oft nicht oder nur teuer erreichbar. | Ergebnis muss in Echtzeit in das eigene Bestandssystem zurückschreiben | Eigenständiges Werkzeug ohne Schnittstellen | Selbst bauen |
| Langfristige Kostenkontrolle | Wie wichtig sind planbare Kosten? Nutzungsbasierte Lizenz- und API-Kosten wachsen mit dem Volumen und können den Business Case kippen (siehe Kapitel D2). | Massenprozess mit Millionen Anfragen pro Jahr | Gelegentliche interne Nutzung durch wenige Personen | Selbst bauen |
Auswertung: Überwiegen Werte von 4 bis 5, spricht das Bild für Eigenentwicklung. Überwiegen niedrige Werte bei gleichzeitig hohem Zeitdruck, ist Kaufen die richtige Wahl. Ein gemischtes Bild mit hoher strategischer Bedeutung, aber fehlender interner Kompetenz spricht für eine Partnerschaft mit klarer Exit-Strategie. Wird die Matrix gar nicht ausgefüllt, entsteht die Entscheidung nach Bauchgefühl oder Anbieterpräsentation, und genau daraus entstehen die teuersten Fehlgriffe: eingekaufte Lösungen, die nicht integrierbar sind, oder Eigenbauten, für die niemand die Kompetenz hat.
Anbieterauswahl: Fragenkatalog
Sobald Kaufen oder Partner die Richtung ist, strukturiert der folgende Katalog die Anbieterauswahl. Er deckt elf Kategorien ab. Zu jeder Frage steht, warum sie gestellt wird und woran eine schlechte Antwort erkennbar ist. Der Katalog wird für jeden Anbieter im Vergleich ausgefüllt; die Antworten gehören in den Vergleich am Kapitelende.
1. Unternehmen und Referenzen
Warum diese Kategorie: Ein Anbieter kann funktional überzeugen und trotzdem in zwei Jahren vom Markt verschwinden. Dann muss die Lösung kurzfristig ersetzt werden, mit allen Migrationskosten.
| Nr. | Frage | Warum wichtig, und worauf achten |
|---|---|---|
| 1.1 | Wie lange besteht der Anbieter am Markt und wie stabil ist er wirtschaftlich? | Junge Anbieter ohne tragfähige Umsätze verschwinden oder werden aufgekauft, oft mit Produkteinstellung. Warnsignal: unter zwei Jahre am Markt und keine nachweisbar zahlende Kundschaft. |
| 1.2 | Welche Referenzkund:innen gibt es in vergleichbarer Branche und Größenordnung? | Eine Referenz aus derselben Branche belegt, dass branchenspezifische Anforderungen (Fachlichkeit, Regulatorik) bereits gelöst wurden. Warnsignal: nur Logos auf der Website, kein Referenzgespräch möglich. |
| 1.3 | Wie sieht die Investorenstruktur aus, und bestehen Abhängigkeiten von einzelnen Geldgebern? | Ein Anbieter, der von einer einzigen Finanzierungsrunde abhängt, kann unter Druck Preise erhöhen oder verkauft werden. Warnsignal: auslaufende Finanzierung ohne erkennbaren Weg zur Profitabilität. |
2. Produkt und Roadmap
Warum diese Kategorie: In Verkaufspräsentationen verschwimmt die Grenze zwischen dem, was heute funktioniert, und dem, was erst geplant ist. Wer auf angekündigte Funktionen baut, trägt das Lieferrisiko des Anbieters.
| Nr. | Frage | Warum wichtig, und worauf achten |
|---|---|---|
| 2.1 | Welche Funktionen sind heute produktiv verfügbar und welche erst in Entwicklung? | Die Kaufentscheidung darf nur auf heute verfügbaren Funktionen beruhen. Praxis: Jede im Gespräch genannte Funktion in einer Testumgebung selbst ausprobieren. |
| 2.2 | Wie transparent und verbindlich ist die Produkt-Roadmap? | Eine öffentliche Roadmap mit Historie zeigt, ob der Anbieter Zusagen einhält. Warnsignal: Roadmap nur mündlich oder „unter NDA". |
| 2.3 | Wie häufig ändern sich Schnittstellen, und wie wird über Änderungen informiert? | Häufige Breaking Changes verursachen laufende Anpassungskosten auf der eigenen Seite. Gut: versionierte APIs mit angekündigten Übergangsfristen von mindestens 12 Monaten. |
3. Daten und Datenhoheit
Warum diese Kategorie: Mit der Nutzung eines Anbieters verlassen eigene Daten das Haus. Was der Anbieter damit tun darf und was nach Vertragsende passiert, muss vor der Unterschrift geklärt sein, danach ist die Verhandlungsposition weg.
| Nr. | Frage | Warum wichtig, und worauf achten |
|---|---|---|
| 3.1 | Wo werden die Daten verarbeitet und gespeichert (Region, Rechenzentrum)? | Datenstandorte außerhalb der EU können DSGVO-Übermittlungsfragen auslösen und für regulierte Branchen unzulässig sein. Konkret nachfragen: auch Sub-Dienstleister und Support-Zugriffe zählen. |
| 3.2 | Werden Kundendaten zum Training der Anbietermodelle verwendet, und lässt sich das ausschließen? | Sonst können eigene Geschäftsdaten indirekt in Modelle einfließen, die auch Wettbewerbern zur Verfügung stehen. Gut: vertraglich zugesicherter Ausschluss, nicht nur eine Opt-out-Einstellung. |
| 3.3 | Wie erfolgt die Löschung nach Vertragsende, und ist ein Datenexport in offenen Formaten möglich? | Ohne Exportmöglichkeit sind die über Jahre angesammelten Daten (Konfigurationen, Feedback, Historie) beim Wechsel verloren. Warnsignal: Export nur in proprietären Formaten oder gegen Zusatzkosten. |
4. Sicherheit
Warum diese Kategorie: Der Anbieter wird Teil der eigenen Angriffsfläche. Eine Sicherheitslücke beim Anbieter ist eine Sicherheitslücke im eigenen Unternehmen (siehe Kapitel B9).
| Nr. | Frage | Warum wichtig, und worauf achten |
|---|---|---|
| 4.1 | Welche Zertifizierungen bestehen (z. B. ISO 27001) und wie aktuell sind sie? | Zertifikate belegen geprüfte Grundprozesse. Warnsignal: abgelaufene Zertifikate oder Zertifikate, die nur für einen Teilbereich des Unternehmens gelten. |
| 4.2 | Wie werden Zugriffskontrolle, Verschlüsselung und Schlüsselverwaltung umgesetzt? | Entscheidet, ob Anbieterpersonal eigene Daten im Klartext sehen kann. Gut: Verschlüsselung mit vom Kunden kontrollierten Schlüsseln, dokumentiertes Berechtigungskonzept. |
| 4.3 | Wie wird mit Sicherheitsvorfällen umgegangen, und in welcher Frist wird informiert? | Die eigene DSGVO-Meldefrist von 72 Stunden ist nur haltbar, wenn der Anbieter selbst schnell meldet. Vertraglich fixieren: Meldefrist von maximal 24 bis 48 Stunden. |
5. Regulatorik und Compliance
Warum diese Kategorie: Beim Einsatz zugekaufter KI bleibt das eigene Unternehmen Betreiber mit eigenen Pflichten nach EU AI Act. Ohne Mitwirkung des Anbieters sind diese Pflichten nicht erfüllbar (siehe Kapitel B8).
| Nr. | Frage | Warum wichtig, und worauf achten |
|---|---|---|
| 5.1 | Welche Rolle nimmt der Anbieter nach EU AI Act ein, und unterstützt er die eigenen Betreiberpflichten? | Betreiber brauchen vom Anbieter Gebrauchsanweisungen, Protokollzugriff und Angaben zu Grenzen des Systems. Warnsignal: Der Anbieter kann die eigene Risikoeinstufung seines Produkts nicht benennen. |
| 5.2 | Werden technische Dokumentation und Nachweise für Hochrisiko-Einstufungen bereitgestellt? | Bei Hochrisiko-Anwendungsfällen sind diese Nachweise Pflicht. Fehlen sie, ist das Produkt für den Anwendungsfall faktisch nicht einsetzbar, egal wie gut es funktioniert. |
| 5.3 | Liegt ein Auftragsverarbeitungsvertrag nach DSGVO vor, und deckt er alle Verarbeitungsschritte ab? | Ohne vollständigen AVV ist die Verarbeitung personenbezogener Daten rechtswidrig. Prüfen: Sind auch KI-spezifische Schritte wie Modellverbesserung und Telemetrie erfasst? |
6. Agentische KI-Fähigkeiten
Warum diese Kategorie: Sobald das Produkt eigenständig handelt (E-Mails versendet, Datensätze ändert, Buchungen auslöst), gelten verschärfte Anforderungen. Ein Agent mit zu weiten Rechten kann realen Schaden anrichten (siehe Kapitel B9).
| Nr. | Frage | Warum wichtig, und worauf achten |
|---|---|---|
| 6.1 | Welche Werkzeuge und Aktionen kann ein Agent des Anbieters ausführen, und wie werden diese begrenzt? | Es muss konfigurierbar sein, welche Aktionen der Agent überhaupt ausführen darf (Prinzip der geringsten Rechte). Warnsignal: Rechte sind nur pauschal an- oder abschaltbar. |
| 6.2 | Ist ein Human-in-the-Loop-Mechanismus für folgenreiche Aktionen vorgesehen und konfigurierbar? | Irreversible Aktionen wie Zahlungen oder Löschungen brauchen eine menschliche Freigabe. Prüfen: Lässt sich je Aktionstyp festlegen, ob eine Freigabe nötig ist? |
| 6.3 | Wie vollständig und exportierbar ist die Protokollierung von Agentenaktionen? | Ohne lückenloses, exportierbares Protokoll ist im Schadensfall nicht rekonstruierbar, was der Agent getan hat, und Audit-Pflichten sind nicht erfüllbar. |
7. Integration und Schnittstellen
Warum diese Kategorie: Der Nutzen entsteht erst, wenn die Lösung in die eigenen Prozesse eingebunden ist. Integrationskosten übersteigen die Lizenzkosten nicht selten um ein Mehrfaches.
| Nr. | Frage | Warum wichtig, und worauf achten |
|---|---|---|
| 7.1 | Welche Standardschnittstellen (APIs) bestehen zu gängigen Kernsystemen (ERP, CRM, DWH)? | Fertige Konnektoren sparen Monate an Integrationsarbeit. Prüfen: Existiert der Konnektor für die eigene Systemversion, nicht nur für das Produkt allgemein? |
| 7.2 | Wie aufwendig ist die Anbindung an die bestehende Datenplattform? | Wenn Daten manuell oder über Umwege übertragen werden müssen, entstehen Fehlerquellen und Doppelhaltung. Gut: automatisierte, protokollierte Anbindung an die eigene Plattform (siehe Kapitel B5). |
| 7.3 | Unterstützt der Anbieter offene Standards, oder erfordert er proprietäre Formate? | Proprietäre Formate verstärken den Lock-in: Jede investierte Stunde bindet stärker an den Anbieter. Offene Standards halten den Wechselpfad offen. |
8. Betrieb und Service Level
Warum diese Kategorie: Sobald ein Geschäftsprozess von der Lösung abhängt, wird die Verfügbarkeit des Anbieters zur eigenen Verfügbarkeit.
| Nr. | Frage | Warum wichtig, und worauf achten |
|---|---|---|
| 8.1 | Welche Verfügbarkeit wird vertraglich zugesichert, und wie wird sie gemessen? | Eine Zusage ohne Messverfahren und ohne Vertragsstrafe ist wertlos. Prüfen: Gilt die Zusage für die Gesamtfunktion oder nur für einzelne Komponenten? |
| 8.2 | Welche Supportzeiten und Eskalationswege bestehen? | Wenn der Prozess rund um die Uhr läuft, reicht Support zu Bürozeiten nicht. Warnsignal: Support nur per Ticket ohne zugesagte Reaktionszeit. |
| 8.3 | Wie transparent ist das Monitoring, und erhält man Einblick in Betriebskennzahlen? | Ohne eigene Sicht auf Störungen und Antwortzeiten bemerkt man Probleme erst durch Beschwerden der Nutzer:innen. Gut: Statusseite plus API-Zugriff auf Kennzahlen. |
9. Skalierbarkeit und Performance
Warum diese Kategorie: Ein Produkt, das im Test mit 100 Anfragen überzeugt, kann bei 100.000 Anfragen pro Tag einbrechen oder unbezahlbar werden.
| Nr. | Frage | Warum wichtig, und worauf achten |
|---|---|---|
| 9.1 | Wie verhält sich die Leistung bei steigendem Anfragevolumen? | Antwortzeiten müssen auch unter Last stabil bleiben. Praxis: Lasttest mit realistischem Zielvolumen vor Vertragsabschluss vereinbaren. |
| 9.2 | Bestehen Kapazitätsgrenzen oder Kontingente, und wie werden sie kommuniziert? | Stille Drosselung (Rate Limits) kann den eigenen Prozess unbemerkt ausbremsen. Grenzen müssen dokumentiert und Überschreitungen aktiv gemeldet werden. |
| 9.3 | Wie wird mit Lastspitzen umgegangen, und welche Mechanismen zur Kostenbegrenzung gibt es? | Bei nutzungsbasierten Preisen kann eine Lastspitze (oder ein Fehler in der eigenen Anbindung) die Monatsrechnung vervielfachen. Gut: konfigurierbare Budgetgrenzen mit Alarm (siehe Kapitel D2). |
10. Kommerzielles
Warum diese Kategorie: Das Preismodell entscheidet über die langfristige Wirtschaftlichkeit stärker als der Einstiegspreis. Die Exit-Konditionen bestimmen die eigene Verhandlungsmacht für alle künftigen Preisrunden.
| Nr. | Frage | Warum wichtig, und worauf achten |
|---|---|---|
| 10.1 | Wie ist das Preismodell aufgebaut (Nutzung, Sitzplätze, Kontingente), und wie transparent ist die Abrechnung? | Das Modell muss zum eigenen Nutzungsprofil passen: Sitzplatzpreise bestrafen breite Nutzung, Nutzungspreise bestrafen hohe Volumina. Die Rechnung muss je Anwendungsfall nachvollziehbar sein. |
| 10.2 | Welche Mindestlaufzeiten und Kündigungsfristen gelten? | Lange Bindung plus unausgereiftes Produkt ist die teuerste Kombination. Warnsignal: Mehrjahresvertrag als Bedingung für den Einstiegsrabatt. |
| 10.3 | Welche Exit-Konditionen bestehen: Datenexport, Übergangsunterstützung, Kosten eines Wechsels? | Wer nicht glaubwürdig wechseln kann, verhandelt künftige Preiserhöhungen aus der schwächeren Position. Exit-Konditionen vor der Unterschrift verhandeln, nicht bei Bedarf. |
11. Nachhaltigkeit und Verantwortung
Warum diese Kategorie: Die eigenen Nachhaltigkeitsziele und Ethik-Leitlinien (siehe Kapitel B10) gelten auch für eingekaufte Lösungen. Was der Anbieter tut, wird dem eigenen Unternehmen zugerechnet, von Kund:innen wie von Aufsichtsgremien.
| Nr. | Frage | Warum wichtig, und worauf achten |
|---|---|---|
| 11.1 | Werden Angaben zum Energieverbrauch oder CO2-Fußabdruck der Modellnutzung bereitgestellt? | Ohne diese Angaben bleibt die eigene Nachhaltigkeitsberichterstattung an dieser Stelle lückenhaft. Gut: Verbrauchskennzahlen je Anfrage oder je Kontingent. |
| 11.2 | Welche Grundsätze zu Fairness und verantwortungsvoller KI-Entwicklung verfolgt der Anbieter? | Diskriminierende Ergebnisse eines zugekauften Modells treffen das eigene Unternehmen als Betreiber. Prüfen: Gibt es veröffentlichte Grundsätze und dokumentierte Bias-Tests? |
| 11.3 | Wie geht der Anbieter mit Bias- und Qualitätsproblemen in eigenen Modellen um, und wie transparent wird berichtet? | Jedes Modell hat Schwächen. Entscheidend ist, ob der Anbieter sie offenlegt und behebt. Warnsignal: „Unser Modell hat kein Bias-Problem" als Antwort. |
Vorlage: Anbietervergleich
Je Kategorie wird eine Bewertung von 1 (schwach) bis 5 (stark) vergeben, gestützt auf die Antworten aus dem Fragenkatalog. K.-o.-Kriterien (etwa fehlender AVV oder kein Datenexport) werden gesondert markiert und führen unabhängig von der Gesamtsumme zum Ausschluss.
| Kategorie | Anbieter A | Anbieter B | Anbieter C |
|---|---|---|---|
| Unternehmen und Referenzen | |||
| Produkt und Roadmap | |||
| Daten und Datenhoheit | |||
| Sicherheit | |||
| Regulatorik und Compliance | |||
| Agentische KI-Fähigkeiten | |||
| Integration und Schnittstellen | |||
| Betrieb und Service Level | |||
| Skalierbarkeit und Performance | |||
| Kommerzielles | |||
| Nachhaltigkeit und Verantwortung | |||
| Summe / K.-o.-Kriterien |
Checkliste: Build-Buy-Partner-Entscheidung startklar
Die Checkliste prüft, ob die Bezugsweg-Entscheidung vollständig abgesichert ist, von der Matrix bis zu den Vertragspunkten:
- Entscheidungskriterien-Matrix für den Anwendungsfall ausgefüllt
- Bezugsweg begründet dokumentiert, nicht nur entschieden
- Bei Kaufen oder Partner: Fragenkatalog für mindestens zwei Anbieter beantwortet
- Anbietervergleich je Kategorie bewertet, K.-o.-Kriterien gesondert markiert
- K.-o.-Kriterien definiert und geprüft (AVV, Datenexport, Trainingsausschluss)
- Datenstandort geklärt, Sub-Dienstleister und Support-Zugriffe eingeschlossen
- Bei agentischen Funktionen: Werkzeugrechte begrenzbar, Human-in-the-Loop konfigurierbar, Protokollierung exportierbar
- Verfügbarkeit, Supportzeiten und Meldefrist bei Sicherheitsvorfällen vertraglich zugesichert
- Preismodell gegen das eigene Nutzungsprofil geprüft, Kostengrenzen und Alarme vereinbart
- Nachhaltigkeits- und Fairness-Grundsätze des Anbieters geprüft, Bias-Tests dokumentiert
- Exit-Strategie und Datenexport vertraglich gesichert
- Regulatorische Rollenverteilung (Anbieter/Betreiber) geklärt
- Ergebnis im Business Case hinterlegt (siehe Kapitel B2)