Standard-Abo, eigene Plattform oder Mischform? Eine Entscheidungshilfe für den Mittelstand

Die Frage taucht in jedem zweiten Gespräch auf: Nehmen wir etwas Fertiges oder bauen wir etwas Eigenes? Sie wird meist als Grundsatzfrage diskutiert, obwohl sie eine Detailfrage ist. Entscheidend ist nicht die Weltanschauung, sondern was Sie erreichen wollen, welche Daten im Spiel sind und wer das Ergebnis später betreiben soll.

Die vier realistischen Varianten

Variante 1: Öffentlicher Dienst mit Standardtarif

Ein allgemein verfügbarer KI-Dienst, genutzt über Geschäftskonten. Schnell verfügbar, geringe Kosten, keine Einrichtung.

Geeignet für: Formulieren, Übersetzen, Zusammenfassen, Recherche zu allgemeinen Themen, Ideensammlung.

Grenzen: Der Dienst kennt Ihr Unternehmen nicht. Für Fragen zu eigenen Unterlagen ist er ungeeignet. Die Datenverarbeitung liegt außerhalb Ihres Einflusses; bei personenbezogenen oder vertraulichen Inhalten ist genau zu prüfen, was der jeweilige Tarif zusichert.

Variante 2: Plattform mit Anbindung an die eigenen Daten

Eine betriebsfertige Plattform, die an Ihre Systeme angebunden wird: Dokumente, Berechtigungen, Anmeldung über Ihr Verzeichnis. Das Modell läuft bei einem Anbieter, idealerweise in Deutschland, auf vertraglicher Grundlage.

Geeignet für: die große Mehrheit mittelständischer Anwendungsfälle – Wissenszugriff, Angebotsunterstützung, interne Auskünfte, Dokumentenarbeit.

Grenzen: Sie bewegen sich im Funktionsrahmen der Plattform. Sehr spezielle Abläufe erfordern Zusatzarbeit oder sind nicht abbildbar.

Variante 3: Plattform plus individuelle Erweiterungen

Wie Variante 2, ergänzt um Anbindungen an Fachsysteme und um Abläufe, die auf Ihr Geschäft zugeschnitten sind – etwa die Verbindung zu ERP, Warenwirtschaft oder einer Branchenlösung.

Geeignet für: Unternehmen, bei denen der Nutzen erst durch die Verbindung mit dem Fachsystem entsteht. Der Rechnungseingang mit Bestellabgleich ist ein typischer Fall.

Grenzen: Höherer einmaliger Aufwand, und Sie brauchen einen Partner, der beides kennt: die Plattform und Ihre Systemlandschaft.

Variante 4: Eigenentwicklung

Aufbau einer eigenen Lösung auf Basis von Modellen und Bibliotheken, betrieben im eigenen Rechenzentrum oder in einer eigenen Cloud-Umgebung.

Geeignet für: Unternehmen mit eigener Entwicklungsmannschaft, besonderen Anforderungen an die Datenhaltung oder einem KI-Bestandteil im eigenen Produkt.

Grenzen: Der Aufwand liegt nicht im ersten Prototyp – der ist in wenigen Wochen fertig und beeindruckt alle. Er liegt im Betrieb: Modellwechsel, Sicherheitsaktualisierungen, Rechteprüfung, Protokollierung, Verfügbarkeit, Weiterentwicklung. Wer das nicht dauerhaft besetzen kann, baut sich eine Altlast.

Die Fragen, die die Entscheidung tatsächlich bestimmen

Brauchen die Antworten Ihr eigenes Wissen?

Wenn ja, scheidet Variante 1 für diesen Anwendungsfall aus. Diese Frage sortiert die meisten Fälle bereits.

Welche Datenkategorien sind betroffen?

Allgemeine Geschäftsinformationen sind unkritischer als Personaldaten, Gesundheitsdaten oder Konstruktionsunterlagen. Je sensibler, desto wichtiger werden Verarbeitungsort, Auftragsverarbeitungsvertrag und die Frage, ob Inhalte gespeichert oder zum Training verwendet werden.

Wer betreibt das in drei Jahren?

Die ehrlichste Frage überhaupt. Eine Eigenentwicklung, die von einer einzelnen Person getragen wird, ist ein Risiko – unabhängig davon, wie gut diese Person ist. Wenn Sie diese Frage nicht klar beantworten können, sprechen die Varianten 2 und 3 für sich.

Wie speziell ist der Ablauf wirklich?

Viele Unternehmen halten ihre Prozesse für einzigartig. Häufig ist die Besonderheit nicht der Ablauf, sondern die Datenquelle. Dann genügt eine Anbindung statt einer Eigenentwicklung.

Wie schnell muss es wirken?

Wenn innerhalb eines Quartals ein Ergebnis stehen soll, ist eine Eigenentwicklung unrealistisch. Wenn Sie ein Jahr Zeit haben und eine Entwicklungsmannschaft, wird sie zur Option.

Der Fehler, der am meisten kostet

Der teuerste Fehler ist nicht die falsche Variante. Er besteht darin, die Frage grundsätzlich statt fallbezogen zu beantworten.

In der Praxis ist eine Mischung fast immer richtig: Für allgemeines Formulieren genügt ein Standardwerkzeug. Für Fragen zum eigenen Wissen braucht es eine angebundene Plattform. Für den einen Ablauf, der wirklich das Geschäft ausmacht, lohnt sich eine individuelle Erweiterung. Eine vollständige Eigenentwicklung ist für die meisten mittelständischen Unternehmen der falsche Weg – nicht wegen der Technik, sondern wegen des Betriebs über Jahre.

Ein Vorgehen, das die Entscheidung erleichtert

Listen Sie Ihre drei wichtigsten Anwendungsfälle auf. Beantworten Sie für jeden die fünf Fragen oben. Sie werden feststellen, dass unterschiedliche Fälle unterschiedliche Antworten bekommen – und genau das ist das Ergebnis.

Beginnen Sie dann mit dem Fall, der den größten Nutzen bei geringstem Aufwand verspricht. Meist ist das ein Fall der Variante 2. Wenn dieser läuft, sind Anbindung, Rechtekonzept, Schulung und Betriebsmodell vorhanden – und der individuelle Fall der Variante 3 wird deutlich günstiger, als er es zu Beginn gewesen wäre.

Worauf Sie bei Anbietern achten sollten

• Verarbeitungsort und Vertrag: Wo läuft das Modell, wer ist Vertragspartner, gibt es einen Auftragsverarbeitungsvertrag, welche Unterauftragnehmer sind beteiligt?
• Berechtigungen: Wie werden sie zum Zeitpunkt der Anfrage geprüft, und wie schnell wirkt ein Rechteentzug?
• Modellunabhängigkeit: Lässt sich das zugrunde liegende Modell wechseln, ohne die Lösung neu zu bauen? Das ist angesichts der Entwicklungsgeschwindigkeit ein handfester Vorteil.
• Nachvollziehbarkeit: Werden Quellen zu Antworten angegeben?
• Ausstieg: Kommen Sie an Ihre Konfiguration und Inhalte heran, wenn Sie wechseln wollen?
• Ansprechpartner: Gibt es jemanden, der Ihre Systemlandschaft kennt – oder nur ein Support-Formular?

Der letzte Punkt wird oft unterschätzt und entscheidet im Alltag mehr als jedes Funktionsmerkmal. Genau deshalb arbeiten wir mit einer eigenen Plattform, die sich an vorhandene Systeme anbinden lässt, statt Ihnen ein geschlossenes Produkt zu verkaufen – und schauen uns vorher an, ob Variante 1 für Ihren Fall nicht schon genügt.

Ein Bewertungsraster für den Vergleich

Wenn mehrere Varianten oder Anbieter nebeneinanderstehen, hilft eine schlichte Bewertung entlang derselben Kriterien. Vergeben Sie je Kriterium Punkte und gewichten Sie nach Ihrer Lage.

• Fachliche Eignung für Ihre zwanzig bis dreißig echten Testfälle.
• Rechtekonzept: Prüfung zum Anfragezeitpunkt, Geschwindigkeit des Rechteentzugs.
• Verarbeitungsort und Vertrag inklusive Unterauftragnehmern.
• Anbindbarkeit an Ihre vorhandenen Systeme.
• Modellunabhängigkeit und Umgang mit Modellwechseln.
• Nachvollziehbarkeit: Quellenangaben, Protokolle.
• Ausstieg: Export von Konfiguration und Inhalten.
• Betreuung: Kennt der Ansprechpartner Ihre Systemlandschaft?
• Gesamtkosten über drei Jahre, nicht nur Lizenz.

Auffällig ist, dass die fachliche Eignung nur eines von neun Kriterien ist. Das entspricht der Erfahrung: Die Unterschiede zwischen brauchbaren Lösungen liegen selten in der Textqualität.

Warum der Prototyp trügt

Eine Beobachtung, die für die Entscheidung zwischen Variante 3 und 4 wichtig ist: Ein erster Prototyp einer Eigenentwicklung ist heute in wenigen Wochen fertig und beeindruckt alle Beteiligten. Genau darin liegt die Falle. Der Aufwand entsteht nicht beim Bauen, sondern beim Betreiben – Rechteprüfung, Protokollierung, Modellwechsel, Sicherheitsaktualisierungen, Verfügbarkeit, Weiterentwicklung, Vertretung im Urlaub.

Fragen Sie deshalb nicht, ob Sie es bauen können, sondern ob Sie es drei Jahre lang betreiben und weiterentwickeln wollen – mit mehr als einer Person, die es versteht.

Häufige Fragen

Können wir mit Variante 1 anfangen und später wechseln?

Ja, und das ist oft sinnvoll. Achten Sie nur darauf, keine Abläufe darauf aufzubauen, die Sie später schwer umstellen können – und regeln Sie von Anfang an, welche Daten hineindürfen.

Was spricht gegen einen reinen Eigenbau auf Open-Source-Basis?

Nichts, wenn Sie eine Entwicklungsmannschaft haben und den Betrieb dauerhaft besetzen können. Mit einer einzelnen Person, die es nebenbei macht, entsteht eine Abhängigkeit, die schwerer wiegt als jede Anbieterbindung.

Wie vermeiden wir Anbieterabhängigkeit?

Über drei Punkte: modelloffene Architektur, Exportmöglichkeit für Konfiguration und Inhalte, und die Vermeidung tief eingebauter Sonderlogik, die nur bei einem Anbieter funktioniert.

Sollten wir auf einen Marktstandard warten?

Warten kostet die Lernkurve. Die Grundlagen, die Sie ohnehin brauchen – saubere Berechtigungen, gepflegte Inhalte, geschulte Mitarbeiter – behalten ihren Wert unabhängig davon, welches Werkzeug sich durchsetzt.

Vier typische Ausgangslagen

Statt abstrakt zu vergleichen, hilft der Blick auf die Situation, in der ein Unternehmen tatsächlich steht. Vier Muster decken die meisten Fälle ab.

Ausgangslage 1: Wir wollen erst einmal verstehen, was das bringt. Kein klarer Anwendungsfall, aber Druck, sich zu befassen. Hier ist Variante 1 richtig – ein Standardtarif für eine überschaubare Gruppe, verbunden mit einer klaren Regel, welche Daten hineindürfen. Ziel ist nicht Produktivität, sondern dass die Beteiligten ein Gefühl für Möglichkeiten und Grenzen entwickeln. Nach drei Monaten wissen Sie, wo der erste echte Fall liegt.

Ausgangslage 2: Unser Wissen ist da, aber nicht auffindbar. Angebote, Projektakten, Serviceberichte – alles vorhanden, niemand findet es. Das ist der häufigste Fall im Mittelstand und der klarste für Variante 2. Der Nutzen entsteht durch die Anbindung, nicht durch Sonderfunktionen.

Ausgangslage 3: Ein Ablauf macht unser Geschäft aus. Die Angebotserstellung in einem Spezialmaschinenbau, die Belegverarbeitung in einem Handelsbetrieb, die Störungsbearbeitung im Service. Hier lohnt Variante 3, weil der Nutzen erst durch die Verbindung mit dem Fachsystem entsteht. Wichtig ist, trotzdem mit Variante 2 zu beginnen und die Erweiterung als zweiten Schritt zu planen.

Ausgangslage 4: KI soll Teil unseres Produkts werden. Dann sprechen wir nicht mehr über interne Werkzeuge, sondern über Produktentwicklung – mit allem, was dazugehört: Betrieb, Haftung, und je nach Produkt die Einordnung nach Anhang I des EU AI Act. Das ist Variante 4, und sie braucht eine Entwicklungsmannschaft.

Was ein Proof of Concept kosten darf

Häufig wird ein Vorprojekt vorgeschlagen, um die Machbarkeit zu zeigen. Das kann sinnvoll sein – wenn drei Bedingungen erfüllt sind.

Erstens ein definiertes Erfolgskriterium. Nicht „wir schauen, was geht“, sondern „von unseren dreißig Testfällen werden mindestens fünfundzwanzig fachlich korrekt und mit Quellenangabe beantwortet“. Ohne dieses Kriterium endet jedes Vorprojekt in einer Geschmacksdiskussion.

Zweitens echte Daten. Ein Vorprojekt mit Beispieldokumenten beweist nichts. Der interessante Teil ist immer, wie das System mit Ihren gewachsenen Beständen umgeht.

Drittens Weiterverwendbarkeit. Was im Vorprojekt entsteht – Anbindung, Rechtekonzept, Testliste – muss in den Produktivbetrieb übernommen werden können. Ein Wegwerf-Prototyp auf einer anderen Grundlage kostet Zeit und beweist wenig.

Als Größenordnung: Ein Vorprojekt sollte deutlich unter dem liegen, was die vollständige Umsetzung kostet, und in vier bis sechs Wochen abgeschlossen sein. Wird es länger oder teurer, ist es kein Vorprojekt mehr, sondern eine Einführung ohne Entscheidung.