Standardlösungen im Bereich KI passen zum Durchschnittsfall. Ihr Unternehmen ist jedoch selten der Durchschnittsfall. Eine Bank, die Kreditrisiken bewertet, ein Verlag, der einen Zusammenfassungsdienst für 20 Sprachen entwickelt, eine Marketingagentur, die kein einziges Dokument außerhalb ihres Netzwerks versenden darf – jeder benötigt ein Modell, das auf den eigenen Daten trainiert und in den eigenen Arbeitsablauf integriert ist. Dieser Leitfaden richtet sich an Führungskräfte, die entscheiden müssen, ob sie ein SaaS-Tool kaufen, ein öffentliches Modell feinjustieren oder eine individuelle Lösung entwickeln. Er behandelt, was individuelle KI tatsächlich bedeutet, wohin Geld und Zeit fließen, woran Projekte scheitern und wie Sie einen Partner auswählen, ohne die Lektion auf die harte Tour zu lernen.
Wichtige Erkenntnisse
| Punkt | Was das in der Praxis bedeutet |
|---|---|
| Individuelle Lösungen sind eine Entscheidung, keine Standardoption | Wenn eine SQL-Abfrage oder eine Standard-API das Problem löst, sollten Sie weder ein Modell noch eine Roadmap darauf aufbauen. |
| Datenarbeit ist das Projekt | In tatsächlichen Projekten von Silk Data verschlingt die Datenaufbereitung 50–65 % des Aufwands. Die Modellierung macht 10–15 % aus. |
| Compliance ist eine Architekturentscheidung | DSGVO, EU-KI-Verordnung, FERPA – diese Vorgaben bestimmen, wo das Modell läuft (Cloud oder On-Premise), bevor Sie Code schreiben. |
| Die meisten Misserfolge sind organisatorisch bedingt | Kein Business Owner, kein Fachexperte, keine Feedback-Schleife. Das Modell wird gebaut und stirbt dann in der Produktion. |
| Anbieterauswahl schlägt Anbieterpreis | Fragen Sie, wer die Architektur entwirft, wem das geistige Eigentum gehört und welche Aufträge im letzten Jahr abgelehnt wurden. |
Was individuelle KI-Entwicklung tatsächlich bedeutet
Individuelle KI-Entwicklung ist der Entwurf, das Training und die Bereitstellung eines Modells auf Basis Ihrer eigenen Daten, Ihres Arbeitsablaufs und Ihrer Compliance-Anforderungen – anstatt auf Basis eines generischen Datensatzes eines Anbieters. Das klingt klar. In der Praxis ist die Grenze zwischen individuell und konfiguriert jedoch fließend.
Es gibt grob vier Optionen auf diesem Spektrum:
- SaaS-KI: ein generisches Produkt, bei dem Sie sich anmelden. Am günstigsten, am schnellsten, mit der geringsten Kontrolle.
- API + Prompt Engineering: ein öffentliches LLM, das mit Ihren Prompts umhüllt wird. Schnelle Erfolge, aber der Anbieter sieht Ihren Datenverkehr.
- Feinjustiertes oder Retrieval-Augmented-Modell: öffentliches Basismodell, Ihre Daten obendrauf, Ihr Bewertungsdatensatz.
- Individuell trainiertes Modell auf Ihrer Infrastruktur: von Grund auf entwickelt oder stark angepasst, häufig On-Premise. Am teuersten, mit maximaler Kontrolle.
Eine praktische Faustregel für die Wahl der Ebene: Ist der Anwendungsfall über viele Unternehmen hinweg wiederholbar und Ihre Daten nicht ungewöhnlich, gewinnt in der Regel die SaaS- oder API-Ebene bei den Gesamtkosten. Sind Ihre Daten so besonders, dass generische Modelle 10–20 % der umsatzrelevanten Fälle verfehlen, beginnt sich Feinjustierung oder RAG auszuzahlen. Ein vollständig individuelles Training ist selten die richtige Antwort – es sei denn, es besteht eine regulatorische Vorgabe oder ein Anspruch auf geistiges Eigentum, der On-Premise-Betrieb erzwingt. Und selbst dann lautet die Frage, ob es sinnvoller ist, ein kleineres Open-Source-Modell auf Ihrer Infrastruktur feinzujustieren, statt von Grund auf neu zu trainieren. Ein Aufbau von Grund auf ist die teuerste Antwort und am seltensten die richtige.
Die ehrliche Antwort liegt für die meisten Teams in den mittleren beiden Optionen. Für einen Werbekunden haben wir mit CatBoost auf zig Millionen Datensätzen ein Modell zur Vorhersage von Klickraten entwickelt. Individuelles Training hat sich ausgezahlt, weil die CTR bei 0,1–0,5 % lag. Keine Standard-API hätte dieses Klassenungleichgewicht bewältigt. Für eine Marketingagentur, die keine Kunden-Briefings ihr Netzwerk verlassen lassen durfte, war ein lokales LLM innerhalb ihrer Plattform die richtige Antwort. Kein von Grund auf entwickeltes Modell. Unterschiedliche Probleme, unterschiedliche Punkte auf dem Spektrum.
Die Vorteile einer individuellen Lösung: Sie besitzen das Modell, kontrollieren die Daten, können es bei geschäftlichen Veränderungen neu trainieren und On-Premise bereitstellen, wenn eine Aufsichtsbehörde oder ein Kunde dies verlangt. Die Nachteile: höhere Anfangskosten, längere Zeit bis zum ersten Ergebnis und laufende Wartungskosten, die nicht enden. Wer Ihnen nur die erste Liste zeigt, verkauft, statt zu beraten. Für einen tieferen Einblick in den Entwicklungspfad hat unser Team ausführlicher über KI- und ML-Entwicklungsdienstleistungen geschrieben.
Wohin Geld und Zeit tatsächlich fließen
Kurz gesagt: Die Datenaufbereitung ist das Projekt. Die Modellierung ist nur ein Bruchteil davon. Die meisten Anbieter zeigen Ihnen diese Aufschlüsselung nicht, weil sie unvorteilhaft wirkt.
Über rund 200 Projekte hinweg sieht unsere interne Aufwandsverteilung so aus:
| Phase | Aufwandsanteil | Was hier geschieht |
|---|---|---|
| Definition der Metriken | ~10 % | In Zahlen festlegen, was „gut“ bedeutet. Die meisten Projekte überspringen dies und bereuen es später. |
| Datenaufbereitung | 50–65 % | Sammeln, bereinigen, kennzeichnen, korrigieren. Hier scheitern Projekte oder werden lebendig. |
| Modellierung | 10–15 % | Trainieren, evaluieren, feinjustieren. Oft weniger Arbeit, als die Demo vermuten lässt. |
| Bereitstellung und Integration | 10–15 % | APIs, Monitoring, Ausweichpfade, Rollback-Pläne. |
| Monitoring | Kontinuierlich | Modelle driften. Daten verschieben sich. Planen Sie dafür von Tag eins an ein Budget ein. |
Ein Posten in dieser Tabelle ist nicht verhandelbar: kontinuierliches Monitoring. Jede andere Phase lässt sich in einer vertretbaren „Light-Variante“ umsetzen – eine schnelle Definition der Metriken, ein minimaler Datenaudit, eine Wrapper-artige Bereitstellung. Nur beim Monitoring bedeutet die „Light-Variante“ faktisch null. Ein Modell ohne Drift-Erkennung fällt nicht sichtbar aus; es fällt leise aus, oft über Monate hinweg. Das ist der teuerste Ausfallmodus im gesamten Lebenszyklus, denn bis er auffällt, sind auf Basis der Modellausgaben bereits geschäftliche Entscheidungen in Gang gesetzt worden.
Zum Zeitplan: Ein fokussierter Proof of Concept benötigt vom Scoping bis zur Go/No-Go-Entscheidung etwa drei Monate. Ein MVP, das tatsächlich in Produktion läuft, verlängert dies in der Regel um weitere drei bis sechs Monate. Ein vollständiger Aufbau mit Integrationen und einer Monitoring-Pipeline liegt meist im Bereich von 6–12 Monaten. Wer Ihnen ein produktionsreifes individuelles Modell in vier Wochen verspricht, verkauft entweder einen Wrapper um eine öffentliche API oder überspringt die entscheidenden Schritte.
Yuliya Marazenko, die unsere KI-Implementierungsarbeit leitet, sagt es unverblümt: Datenqualität ist wichtiger als der Algorithmus. Bei einem Prognoseprojekt zur Tiergesundheit für einen landwirtschaftlichen Kunden fanden wir einen Datensatz, der ein einzelnes Tier mit mehreren Dutzend Tonnen auflistete. Kein Modell der Welt hätte ein brauchbares Ergebnis geliefert, bevor diese Zeile gefunden und korrigiert wurde. Das ist es, wofür 50–65 % des Budgets aufgewendet werden – die Arbeit, die alles Weitere erst möglich macht. Für Teams, die ein erstes Projekt umreißen, deckt ein strukturierter KI-Proof-of-Concept diese Realitäten meist kostengünstig auf.
Compliance ist eine Architekturentscheidung, kein Häkchen auf einer Liste
Die kurze Antwort: In regulierten Branchen bestimmt Ihr Compliance-Regime, wo das Modell läuft und welche Daten Ihr Netzwerk überhaupt verlassen. Diese Entscheidung fällt in der Architekturphase, nicht beim Launch.
Drei Regelwerke sind für europäische und US-amerikanische Unternehmenszielgruppen am wichtigsten, und sie greifen jeweils in unterschiedlichen Bereichen:
- DSGVO gilt immer dann, wenn personenbezogene Daten im EU-Kontext verarbeitet werden. Sie regelt, was Sie wo und wie lange speichern dürfen. Der offizielle DSGVO-Text ist die maßgebliche Quelle.
- Die EU-KI-Verordnung klassifiziert KI-Systeme nach Risikostufen und legt Pflichten für Anwendungen mit hohem Risiko fest, etwa Kreditbewertung oder Personaleinstellung.
- Das NIST AI RMF ist eine freiwillige US-Leitlinie zum Management von KI-Risiken, die sich auch außerhalb der USA als Rahmen eignet.
- FERPA steht für sich und gilt ausschließlich für US-Bildungsdaten – relevant für EdTech, jedoch nicht für eine deutsche Bank.
Ein Hinweis zum Zeitplan, der für die aktuelle Planung wichtig ist: Die Einigung zum Digital Omnibus zur KI vom Mai 2026 hat die Pflichten für Hochrisikoanwendungen nach Anhang III von August 2026 auf Dezember 2027 verschoben; bei eingebetteten Hochrisikoprodukten wurde die Frist bis August 2028 verlängert. Dies erweitert das Planungsfenster – ändert aber nichts an der Architekturentscheidung. Wenn Ihr Anwendungsfall als hochriskant eingestuft wird, müssen die Anforderungen an Dokumentation, Data Governance und menschliche Aufsicht dennoch von Anfang an mitgedacht werden. Die Verlängerung als Vorwand zu nehmen, um die Architekturarbeit aufzuschieben, ist genau der Weg, auf dem Organisationen später Compliance zu einem Mehrfachen der Kosten nachrüsten.
Dies sind rechtliche Rahmenwerke, keine technischen. Die technische Umsetzung läuft meist auf eine von drei Optionen hinaus: die Daten im eigenen Netzwerk behalten, sie vor dem Verlassen anonymisieren oder einen Anbieter mit passender vertraglicher Position wählen. Für einen deutschen Verlagskunden betreiben wir seit Jahren ein lokales LLM über deren Archive. Die Rechtsabteilung benötigte die Sicherheit, dass nichts die Infrastruktur verlässt, und die Architektur musste dies vom ersten Tag an leisten. Eine spätere Nachrüstung hätte den Wiederaufbau des Systems bedeutet.
Polina Volodina, die Kunden in KI-Strategie berät, fasst den Zielkonflikt gut zusammen: Cloud-APIs lassen sich schneller starten und günstiger einführen. On-Premise-Bereitstellungen verursachen höhere Anfangskosten, eliminieren aber eine ganze Kategorie rechtlicher und geschäftlicher Risiken. Keine der beiden Optionen ist grundsätzlich richtig. Die Frage lautet, welche Risiken Ihr Unternehmen tragen kann. Unsere KI-Beratung beginnt in der Regel genau mit diesem Gespräch.
Individuell vs. Standardlösung: wann sich welche Option lohnt
Standardlösungen gewinnen, wenn Ihr Problem dem aller anderen ähnelt. Individuelle Lösungen gewinnen, wenn Genauigkeit, Kontrolle oder Compliance echten geldwerten Nutzen bringen.
| Dimension | Standard-SaaS | Individuell oder stark angepasst |
|---|---|---|
| Zeit bis zum ersten Ergebnis | Tage bis Wochen | Monate |
| Anfangskosten | Niedrig | Höher |
| Langfristige Kosten | Wiederkehrende SaaS-Gebühren, oft steigend | Vorhersehbar, im Eigentum |
| Genauigkeit bei Ihren Daten | Generischer Ausgangswert | Auf Ihre Fachdomäne abgestimmt |
| Kontrolle über den Datenstandort | Vom Anbieter abhängig | Bei Ihnen, einschließlich On-Premise |
| Eigentum am geistigen Eigentum | Anbieter | Sie |
| Anbieterbindung | Hoch | Gering |
Ein nützlicher Filter: Schätzen Sie die Kosten einer falschen Antwort. Bei einem internen Notizassistenten kostet eine falsche Zusammenfassung eine Minute. Bei einer Betrugsprüfung kostet sie einen Kunden oder eine Geldbuße. Je höher dieser Wert, desto stärker rechnet sich eine individuelle Lösung. Ein zweiter Filter: Wie ungewöhnlich sind Ihre Daten? Wir haben eine semantische Suche über 6 Millionen Bilder auf ElasticSearch mit einer eigenen Vektor-Schicht aufgebaut. Das war niemals von einer SaaS-Lösung zu erwarten. Der Umfang und die Art der Assets schlossen dies aus. Ein Vertriebsteam, das Meeting-Transkripte zusammengefasst haben möchte, sollte wahrscheinlich einfach ein Tool kaufen.
Ein ehrlicher Gegenpunkt zur individuellen Lösung: Sie übernehmen auch die Wartung. Ein Modell ist kein einmaliges Liefergegenstand, sondern ein Produkt, das kontinuierliche Pflege brzucht. Wenn Ihr Unternehmen Monitoring und Neutraining nicht über Jahre finanzieren will, ist die Standardlösung die sicherere Wahl, selbst bei geringerer Genauigkeit.
Warum individuelle KI-Projekte scheitern und was tatsächlich hilft
Die meisten Misserfolge sind nicht technischer, sondern organisatorischer Natur. Nach über 200 Projekten wiederholen sich die Muster oft genug, um sie vorhersagen zu können.
Die häufigsten Ausfallmuster:
- Kein Business Owner. Ein Modell ohne verantwortliche Person auf Geschäftsseite wird innerhalb eines Quartals zur Waise. Niemand entscheidet, wann es neu trainiert werden soll oder was zu tun ist, wenn es sich fehlverhält.
- Kein Zugang zu Fachexperten. Wenn die Underwriter, Ärzte oder Redakteure, die die Fachdomäne kennen, dem Team nicht eine Stunde pro Woche geben können, wird das Modell aus Kennzeichnungen lernen, die richtig aussehen und falsch sind.
- Falsche Erfolgsmetrik. Genauigkeit sieht auf einem ausgewogenen Testdatensatz großartig aus und fällt bei einer positiven Klasse von 0,3 % zusammen. Wählen Sie die Metrik vor dem Training.
- Modellierung vor der Datenarbeit. Teams stürzen sich auf das Training, weil es interessanter ist als das Bereinigen. Die Bereinigung muss ohnehin stattfinden – und wird später teurer.
- Anbieter nach Preis ausgewählt. Ein niedriges Angebot bedeutet meist, dass der Anbieter die Datenarbeit, die Compliance-Arbeit oder beides unterschätzt hat. Die Differenz zahlen Sie später.
Die Lösung ist nicht exotisch. Benennen Sie einen Business Owner vor dem Kickoff. Reservieren Sie Zeit von Fachexperten vertraglich. Definieren Sie die Metrik in der ersten Woche. Geben Sie das Datenbudget vor dem Modellierungsbudget aus. Yuri Svirid, unser CEO, hat aus 30 Jahren in EdTech und FinTech eine Regel: Wenn SQL das Problem löst, sagen Sie es und verkaufen Sie nicht ein Modell obendrauf. Umgekehrt gilt das auch. Wenn ein Modell die richtige Antwort ist, tun Sie nicht so, als würde ein Dashboard genügen.
Ein unterschätztes Risiko: Modell-Drift. Ein Kundenabwanderungsmodell, das auf Verhaltensdaten von 2023 trainiert wurde, verschlechtert sich im Laufe von 2024 unmerklich. Sie benötigen eine Monitoring-Pipeline, die Drift meldet, und einen Neutrainings-Zeitplan, der nicht davon abhängt, ob sich jemand daran erinnert. Diese Arbeit ist unspektakulär und trennt ein Projekt von einem Produkt. Für Teams, die über den ersten Launch hinausdenken, deckt unsere Arbeit zu DevOps und MLOps die Pipeline-Seite ab.
Wie Sie einen Partner auswählen, ohne es auf die harte Tour zu lernen
Die kurze Antwort: Prüfen Sie die Ingenieurin oder den Ingenieur, die Ihre Architektur verantworten werden – nicht das Logo auf dem Angebot.
Eine kurze Liste von Fragen, die seriöse Anbieter von hochglanzpolierten unterscheidet:
- Wer entwirft die Architektur und kann ich diese Person vor Vertragsabschluss kennenlernen? Wenn die Antwort ein Vertriebsingenieur ist, den Sie nie wieder sehen werden, dann ist das das Projekt.
- Erzählen Sie mir von einem Projekt, das schiefgegangen ist. Wer echte Narben hat, wird eine klare Antwort geben. Wer keine hat, hat noch nicht genug ausgeliefert.
- Welche Aufträge haben Sie im letzten Jahr abgelehnt und warum? Ein Partner, der niemals Nein gesagt hat, verkauft, statt zu beraten.
- Wem gehören das Modell, die Gewichte und die Trainingsdaten nach der Übergabe? Halten Sie das im Vertrag fest, nicht in der Präsentation.
- Wie handhaben Sie die Kosten für die Datenaufbereitung? Wenn die Antwort pauschal 10 % lautet, ist das entweder geraten oder verschleiert.
- Wie sieht das Modell für den Support nach dem Launch aus? Monitoring, Neutrainings-Rhythmus, Notfall-Rollback, Rufbereitschaft – für all das sollten Namen genannt werden.
Was Sie mit den Antworten anfangen. Bewerten Sie jeden Anbieter anhand dieser Fragen, bevor Sie die Preise vergleichen. Ein Anbieter, der ein gescheitertes Projekt benennen kann, auf Architekturen verweist, die er abgelehnt hat, und seinen leitenden Ingenieur vor Vertragsabschluss in ein Gespräch bringt, spielt in einer anderen Liga als einer mit polierten Folien und einem Vertriebsingenieur. Die Preisdifferenz zwischen diesen Kategorien beträgt in der Regel 30–50 %. Die Kostendifferenz, gemessen über 18 Monate einschließlich der Kosten für gescheiterte Bereitstellungen und ungeplante Nacharbeiten, gleicht diesen Unterschied meist aus oder kehrt ihn um.
Noch ein praktischer Punkt. Langfristige Partnerschaften schlagen kurzfristige in der KI-Arbeit, weil das Modell niemals fertig ist. Unser Team arbeitet seit sieben Jahren mit einem deutschen Verlag (Reemers) zusammen, über drei ihrer CTOs hinweg. Das institutionelle Wissen darüber, warum ein Modell auf bestimmte Weise gebaut wurde, ist mehr wert als jede Dokumentation. Diese Art von Kontinuität lässt sich schwer vortäuschen und ist eine Nachfrage wert. Der Bereich mit Fallstudien ist ein guter Ort, um zu sehen, was wir unter langfristiger Zusammenarbeit verstehen.
Über Silk Data
Wenn Sie zwischen Eigenentwicklung und Kauf abwägen, ist die günstigste Stunde, die Sie investieren können, ein Scoping-Gespräch mit jemandem, der bereits Probleme dieser Art umgesetzt hat. Unser Team hat On-Premise-LLMs für Kunden aufgebaut, die keine Daten ihr Netzwerk verlassen lassen dürfen, semantische Suche über Millionen von Assets, Vertragsanalyse aus PDFs und Pipelines zur Lebenslauf-Sichtung für Einstellungen im großen Maßstab. Wir haben Kunden aber auch geraten, SQL zu verwenden und das Modell wegzulassen. Beide Antworten gehören zum Job.
Wenn ein strukturierter Ausgangspunkt hilfreich wäre: Unser Team bietet kurze Scoping-Engagements an, die mit einer Go/No-Go-Entscheidung enden – nicht mit einer Verkaufspräsentation. Schreiben Sie an hello@silkdata.ai mit dem Problem, den vorhandenen Daten und der Einschränkung, die Sie am meisten beunruhigt.
Häufig gestellte Fragen
Ein Proof of Concept läuft vom Scoping bis zur Go/No-Go-Entscheidung meist etwa drei Monate. Ein MVP in Produktion verlängert dies um weitere drei bis sechs Monate. Ein vollständiger Aufbau mit Integrationen und Monitoring liegt meist im Bereich von 6–12 Monaten. Die Zeitpläne hängen stärker vom Datenreifegrad ab als von der Modellkomplexität. Wenn Ihre Daten sauber, gekennzeichnet und zugänglich sind, geht alles schneller.
Nach unserer Erfahrung aus über 200 Projekten verschlingt die Datenaufbereitung 50–65 % des Aufwands. Die Definition der Metriken macht rund 10 % aus. Die Modellierung selbst liegt bei 10–15 %. Bereitstellung und Integration sind weitere 10–15 %. Das Monitoring ist offen und läuft über die gesamte Lebensdauer des Modells. Anbieter, die behaupten, die Modellierung sei der Löwenanteil der Arbeit, verschleiern in der Regel den Datenschritt, in dem die tatsächlichen Kosten stecken.
Wählen Sie eine individuelle Lösung, wenn eines von drei Kriterien zutrifft: Die Kosten einer falschen Antwort sind hoch (Betrug, Kredit, medizinische Triage), Ihre Daten oder Arbeitsabläufe sind so ungewöhnlich, dass generische Modelle das Muster verfehlen, oder Compliance verlangt eine On-Premise-Bereitstellung. Trifft nichts davon zu, ist eine Standardlösung meist schneller und günstiger. Der ehrliche Test lautet, ob sich die Genauigkeitsdifferenz zwischen generischem und individuellem Modell in Ihrem Unternehmen in Geld übersetzen lässt.
Behandeln Sie Compliance als Architekturentscheidung, nicht als Checkliste vor dem Launch. Gilt die DSGVO, muss die Frage, wo die Daten liegen, vor Trainingsbeginn beantwortet sein. Klassifiziert die EU-KI-Verordnung Ihren Anwendungsfall als hochriskant, prägen die Dokumentations- und Aufsichtspflichten Ihren Entwicklungsprozess. Für US-Bildungsdaten entscheidet FERPA darüber, was Sie überhaupt verwenden dürfen. Beziehen Sie Recht und Data Governance in die Discovery-Phase ein. Diese Entscheidungen nachträglich einzubauen, nachdem das Modell existiert, ist stets teurer, als von Anfang an darauf hin zu entwickeln.
Planen Sie kontinuierliches Monitoring, regelmäßiges Neutraining, Infrastruktur und Sicherheitspatches ein. Der genaue Anteil an den ursprünglichen Entwicklungskosten variiert, aber die Arbeit endet nicht mit der Übergabe. Modelle driften, während sich die Welt um sie herum verändert. Ein Abwanderungsmodell, das auf den Kunden des Vorjahres trainiert wurde, wird in diesem Jahr unmerklich schlechter. Planen Sie ab Tag eins mit einem benannten Verantwortlichen, einer Monitoring-Pipeline und einem Neutrainings-Rhythmus – nicht als Überraschung in Monat neun.
