Eigene KI-Lösung vs KI-Tool: Was lohnt sich für Unternehmen?

Ein Mitarbeiter kopiert eine Kundenanfrage aus dem CRM in ein KI-Tool, ergänzt Preisinformationen aus einer Datei und überträgt die Antwort anschließend wieder zurück. Das Tool formuliert brauchbare Texte. Der eigentliche Vorgang bleibt trotzdem manuell, fehleranfällig und außerhalb des CRM nicht nachvollziehbar. Eigene KI-Lösung vs KI-Tool: Für diesen Vorgang ist das keine technische Geschmacksfrage, sondern eine Entscheidung über Integration und Verantwortung.

An diesem Punkt entsteht häufig die Frage nach einer eigenen KI-Lösung. Gemeint ist damit selten ein selbst trainiertes Sprachmodell. In der Praxis geht es meist um eine individuelle Anwendung, die ein vorhandenes Modell kontrolliert nutzt, Unternehmensdaten gezielt bereitstellt und Aktionen über freigegebene Schnittstellen ausführt. Ob dieser Aufwand sinnvoll ist, entscheidet nicht die Leistungsfähigkeit einer Demo. Maßgeblich sind Prozess, Daten, Integrationsbedarf, Fehlerrisiko und laufender Betrieb.

Eigene KI-Lösung vs KI-Tool: vier Bereitstellungsmodelle

Die Gegenüberstellung „KI-Tool kaufen oder KI selbst entwickeln“ greift zu kurz. Zwischen einem öffentlich verfügbaren Assistenten und einem eigenen Modell liegt ein breites Feld.

Eine individuelle KI-Anwendung kann beispielsweise eine Anfrage im CRM öffnen, passende Vertragsdaten abrufen, einen Antwortentwurf erzeugen und ihn einem zuständigen Mitarbeiter zur Freigabe vorlegen. Das zugrunde liegende Modell kommt weiterhin von einem spezialisierten Anbieter. Eigen sind Prozess, Benutzeroberfläche, Datenzugriff, Regeln, Protokollierung und Systemintegration.

Diese Trennung ist wirtschaftlich wichtig. Wer „eigene KI“ automatisch mit Modelltraining gleichsetzt, kalkuliert eine unnötig große Lösung. Wer dagegen jedes Problem mit einem Standard-Chatfenster lösen will, lässt den aufwendigen Teil des Geschäftsprozesses beim Mitarbeiter.

Die Entscheidung beginnt beim konkreten Arbeitsvorgang

Ein sinnvoller Vergleich braucht einen klar begrenzten Vorgang. „Texte mit KI erstellen“ ist zu unscharf. „Aus einer eingehenden Serviceanfrage einen Antwortentwurf erzeugen, Garantiebedingungen prüfen und den Vorgang nach Freigabe im Ticketsystem dokumentieren“ lässt sich bewerten.

Für die Aufnahme genügen zunächst sechs Angaben:

• Auslöser: Welches Ereignis startet den Vorgang?
• Eingaben: Welche Dokumente, Datensätze und Kontextinformationen werden benötigt?
• Ergebnis: Was muss am Ende im führenden System stehen?
• Entscheidung: Welche fachlichen Regeln beeinflussen den Ablauf?
• Fehlerfolge: Was passiert bei einer falschen Aussage oder Aktion?
• Menge: Wie häufig tritt der Vorgang auf und wie stark schwankt er?

Die Analyse von Geschäftsprozessen macht daraus einen prüfbaren Ablauf mit Eingaben, Rollen und Übergaben. Erst danach ist erkennbar, ob ein vorhandenes Tool den vollständigen Vorgang abdeckt oder lediglich einen einzelnen Arbeitsschritt beschleunigt.

Ein Standardprodukt darf dabei gewinnen. Wenn fünf Mitarbeiter gelegentlich interne Texte zusammenfassen und das Ergebnis vor jeder Verwendung prüfen, ist eine individuelle Anwendung meist überdimensioniert. Müssen dagegen täglich Anfragen mit kundenbezogenen Daten, Lieferstatus und Vertragsregeln bearbeitet werden, werden Integration und Kontrolle zum Kern der Lösung.

Fertige KI-Tools passen zu allgemeinen und reversiblen Aufgaben

Ein fertiges Tool ist stark, wenn der Arbeitsablauf dem Standard vieler anderer Unternehmen entspricht. Recherche in freigegebenen Quellen, Entwürfe für interne Texte, Zusammenfassungen und erste Strukturvorschläge benötigen häufig keine eigene Software.

Für diese Variante sprechen:

• die Funktion ist bereits im Produkt vorhanden und fachlich ausreichend
• Daten lassen sich ohne riskante Hilfskonstruktionen bereitstellen
• das Ergebnis wird vor einer geschäftlichen Wirkung von einem Menschen geprüft
• benötigte Rollen und Administrationsfunktionen sind im gewählten Tarif enthalten
• ein späterer Wechsel ist mit vertretbarem Aufwand möglich
• die Lizenzkosten bleiben auch bei steigender Nutzerzahl nachvollziehbar

Der bestehende Überblick zu KI-Tools für den Mittelstand ordnet typische Werkzeugklassen ein. Die Auswahl endet allerdings nicht beim Funktionsvergleich. Ein Unternehmen benötigt auch Regeln für erlaubte Daten, freigegebene Nutzer, gemeinsame Arbeitsbereiche, Aufbewahrung und den Umgang mit erzeugten Inhalten.

Ein günstiges Einzelkonto kann für einen Test reichen. Für den regulären Betrieb zählen zentrale Administration, Rollen, Protokolle, Vertragsgrundlagen und verlässliche Deaktivierung ehemaliger Nutzer. Fehlen diese Funktionen, wird aus dem schnellen Einstieg eine schwer kontrollierbare Schattenlösung.

Konfiguration und Integration schließen die Lücke zum Standard

Viele Anforderungen rechtfertigen noch keine vollständige Eigenentwicklung. Eine Plattform kann fachlich passen, benötigt aber eine saubere Konfiguration oder einen kontrollierten Datenaustausch.

Ein Beispiel ist eine interne Wissenssuche. Das fertige Produkt liefert Authentifizierung, Suche und Antwortoberfläche. Das Unternehmen definiert zulässige Dokumentbereiche, synchronisiert Inhalte aus dem DMS und legt fest, welche Nutzer welche Quellen sehen dürfen. Eine solche Lösung bleibt ein Standardprodukt, obwohl die Einführung mehr umfasst als den Kauf von Lizenzen.

Auch ein vorhandener Konnektor ist nicht automatisch eine belastbare Integration. Entscheidend sind konkrete Eigenschaften:

• übertragene Felder und zulässige Datenklassen
• Zeitpunkt und Richtung der Synchronisation
• Verhalten bei Dubletten, Löschungen und widersprüchlichen Werten
• technische Identität und Berechtigungen des Konnektors
• Protokollierung fehlgeschlagener Übertragungen
• Rücknahme bereits ausgeführter Änderungen

Fehlt dem Tool nur eine klar begrenzte Verbindung, kann eine API-Entwicklung wirtschaftlicher sein als der Neubau der gesamten Anwendung. Bleiben dagegen Oberfläche, Prozesslogik, Rechte und Integration dauerhaft gegen das Produktmodell gerichtet, wächst die Konfiguration zu einer fragilen Ersatzentwicklung.

Eine individuelle KI-Lösung trägt den eigenen Geschäftsprozess

Eigenentwicklung wird interessant, wenn der Prozess einen echten betrieblichen Unterschied macht und ein Standardprodukt ihn nicht ohne dauerhafte Umwege abbildet. Typische Signale sind tiefe Zugriffe auf CRM, ERP oder Fachsoftware, kundenspezifische Regeln, mehrere Freigabestufen und eine eigene Benutzerführung.

Eine individuelle Lösung kann beispielsweise folgende Kette steuern:

1. Eine Anfrage wird einem vorhandenen Kunden und Auftrag zugeordnet.
2. Das System lädt ausschließlich die für diesen Vorgang erlaubten Informationen.
3. Das Modell klassifiziert das Anliegen und erstellt einen strukturierten Vorschlag.
4. Fachregeln prüfen Preisangaben, Fristen und Pflichtfelder.
5. Ein Mitarbeiter sieht Quellen, Vorschlag und erkannte Unsicherheiten in einer Oberfläche.
6. Nach Freigabe werden Antwort und Bearbeitungsstatus im CRM gespeichert.

Hier entsteht der Nutzen nicht durch einen besseren Textgenerator. Er entsteht, weil der Medienbruch verschwindet, Kontext automatisch bereitsteht und jeder Vorgang einen dokumentierten Status erhält. Der Artikel zu KI-Agenten im Unternehmen vertieft die Grenzen schreibender Systemaktionen und die nötigen Werkzeugrechte.

Eine eigene Anwendung erleichtert außerdem den Austausch einzelner Komponenten. Modell, Vektorsuche, Dokumentenspeicher oder Workflow können über klar definierte Schnittstellen angebunden werden. Diese Austauschbarkeit entsteht jedoch nicht von selbst. Prompts, Ausgabeschemata und Modelleigenschaften dürfen nicht unkontrolliert über den gesamten Anwendungscode verteilt sein.

Ein eigenes Grundmodell bleibt ein begründungsbedürftiger Sonderfall

Ein selbst betriebenes offenes Modell kann sinnvoll sein, wenn eine bestätigte Anforderung externe Verarbeitung ausschließt, sehr hohe und gleichmäßige Nutzung eine eigene Infrastruktur rechtfertigt oder ein spezialisiertes Modell nachweisbar bessere Ergebnisse liefert. Dafür müssen ausreichend Daten, Testfälle und Betriebskompetenz vorhanden sein.

Der Betrieb umfasst mehr als einen Server mit Grafikprozessor. Benötigt werden Versionsverwaltung, Kapazitätsplanung, Sicherheitsupdates, Zugriffsschutz, Überwachung, Sicherung der Konfiguration und ein kontrollierter Modellwechsel. Auch ein lokal betriebenes Modell löst Datenschutz- und Qualitätsfragen nicht automatisch. Es kann personenbezogene Eingaben verarbeiten, ungeeignete Ausgaben erzeugen oder über eine unsichere Anwendung zugänglich sein.

Für viele mittelständische Anwendungen ist eine eigene Prozessanwendung auf einer verwalteten Modell-API der vernünftigere Mittelweg. Das Unternehmen kontrolliert die fachlich relevanten Teile, ohne Modellinfrastruktur zu seinem neuen Kerngeschäft zu machen.

Prozesspassung und Differenzierung bestimmen den vertretbaren Aufwand

Eine eigene Lösung lohnt sich selten für einen Vorgang, der im Unternehmen genauso abläuft wie bei tausenden anderen Nutzern. Je spezifischer und wertvoller der Prozess, desto eher kann Individualisierung wirtschaftlich werden.

Eine belastbare Bewertung trennt drei Ebenen:

Der Vergleich individuelle Software oder Standardsoftware behandelt die allgemeine Softwareentscheidung. Bei KI kommt eine zusätzliche Unsicherheit hinzu: Das Ergebnis ist probabilistisch. Selbst eine gute Architektur benötigt reale Testfälle, messbare Qualitätsgrenzen und einen definierten Rückfallweg.

Integration entscheidet über echte Entlastung

Ein Tool kann eine Aufgabe fachlich hervorragend lösen und den Gesamtprozess trotzdem kaum verbessern. Wenn Mitarbeiter Daten hineinkopieren, Ergebnisse zurückübertragen und den Status manuell pflegen, bleiben Wartezeit und Fehlerquellen bestehen.

Der Integrationsbedarf lässt sich an vier Stufen ablesen:

1. Manuelle Nutzung: Nutzer übertragen Eingabe und Ergebnis selbst. Das passt für seltene, reversible Aufgaben.
2. Lesender Zugriff: Die KI erhält gezielt freigegebene Daten aus Unternehmenssystemen. Berechtigungen und Quellenfilter werden wichtig.
3. Vorbereitende Aktion: Die Lösung erstellt Datensätze oder Änderungen als Entwurf. Ein Mensch bestätigt sie im führenden System.
4. Schreibende Aktion: Das System verändert Status, sendet Nachrichten oder löst Folgeprozesse aus. Validierung, Rechte, Protokolle und Rücknahme sind Pflichtbestandteile.

Je höher die Stufe, desto weniger reicht ein isoliertes KI-Tool. Die Systemintegration im Mittelstand beschreibt, wie führende Systeme, Datenverantwortung und Fehlerwege festgelegt werden. Eine individuelle KI-Oberfläche ohne verlässliche Schnittstellen würde lediglich eine weitere Dateninsel schaffen.

Datenkontrolle wird pro Datenfluss bewertet

„Der Anbieter ist DSGVO-konform“ ist keine ausreichende Prüfung. Relevant ist, welche Daten eine konkrete Funktion verarbeitet, zu welchem Zweck sie übertragen werden, wo sie gespeichert bleiben und wer Zugriff erhält. Auch Funktionen desselben Anbieters können unterschiedliche Aufbewahrungsbedingungen haben.

OpenAI beschreibt für seine API beispielsweise, dass API-Eingaben und -Ausgaben standardmäßig nicht zum Training verwendet werden, sofern der Kunde nicht aktiv zustimmt. Gleichzeitig können standardmäßig Missbrauchsprotokolle bis zu 30 Tage aufbewahrt werden; bestimmte Funktionen speichern zusätzlichen Anwendungszustand. Zero Data Retention ist nur für berechtigte Kunden und unterstützte Endpunkte verfügbar. Diese Details zeigen, warum eine pauschale Aussage über „die API“ nicht genügt.

Für jede betrachtete Lösung sollte ein Datenblatt mindestens festhalten:

• Kategorien der Eingaben und erzeugten Ausgaben
• personenbezogene, vertrauliche oder besonders geschützte Inhalte
• beteiligte Anbieter, Unterauftragnehmer und externe Werkzeuge
• Speicherorte, Aufbewahrungsdauer und Löschmöglichkeit
• Nutzung für Training, Produktverbesserung oder Missbrauchskontrolle
• technisch verfügbare Mandanten-, Rollen- und Protokollfunktionen
• Exportmöglichkeiten bei Vertragsende

Der Europäische Datenschutzausschuss behandelt in seiner Stellungnahme 28/2024 unter anderem die Anonymität von KI-Modellen, mögliche Rechtsgrundlagen und Folgen rechtswidrig verarbeiteter Trainingsdaten. Daraus folgt keine pauschale Freigabe oder Ablehnung eines Produkts. Der konkrete Verarbeitungszweck und die tatsächlichen Schutzmaßnahmen bleiben prüfungsbedürftig.

Qualität braucht eigene Testfälle statt Herstellerwerte

Ein Standardtool wird häufig mit allgemeinen Benchmarks oder einer überzeugenden Testeingabe bewertet. Für eine Geschäftsentscheidung sind eigene Fälle wichtiger. Ein Angebotsassistent muss mit unvollständigen Anfragen, abweichenden Produktnamen, widersprüchlichen Preisen und fehlenden Kundendaten umgehen können. Genau diese Grenzfälle erzeugen später den Prüfaufwand.

Ein kleines Evaluationsset sollte typische Fälle, schwierige Fälle und unzulässige Aktionen enthalten. Für jeden Fall werden erwartete Felder, erlaubte Abweichungen und eine Fehlerfolge definiert. Mögliche Messgrößen sind:

• fachlich korrekte Klassifikation
• vollständig und korrekt belegte Aussagen
• Einhaltung des geforderten Ausgabeformats
• Anteil notwendiger manueller Korrekturen
• korrekte Übergabe bei fehlendem Kontext
• unterlassene Aktion bei fehlender Berechtigung
• Laufzeit und variable Nutzungskosten je Vorgang

Das NIST AI Risk Management Framework ordnet KI-Risiken über Govern, Map, Measure und Manage. Sein Profil für generative KI ergänzt konkrete Risiken und Maßnahmen für generative Systeme. Für die Werkzeugauswahl bedeutet das: Risiko und Qualität werden über den gesamten Nutzungskontext bewertet, nicht allein am Modellnamen.

Eine individuelle Anwendung schafft bessere Möglichkeiten für solche Tests, garantiert aber keine höhere Qualität. Ohne versionierte Prompts, gespeicherte Testfälle und Überwachung kann sie sogar schwerer zu warten sein als ein gutes Standardprodukt.

Gesamtkosten entstehen an unterschiedlichen Stellen

Der monatliche Lizenzpreis und die einmaligen Entwicklungskosten lassen sich nicht direkt vergleichen. Beide Varianten erzeugen weitere Aufwände, nur an anderen Stellen.

Ein Standardtool wird mit wachsender Nutzerzahl teuer, wenn jeder gelegentliche Nutzer eine volle Lizenz benötigt. Eine API-Lösung kann bei hoher Nutzung variable Kosten erzeugen, vor allem bei langen Eingaben, großen Wissensbeständen oder wiederholten Modellaufrufen. Eine eigene Anwendung hat höhere Anfangskosten, kann aber einen vollständigen Vorgang statt einzelner Nutzerplätze abbilden.

Für die Entscheidung werden deshalb mindestens drei Szenarien gerechnet: heutige Nutzung, erwartete Nutzung nach Einführung und ein realistischer Spitzenfall. Interne Prüfzeit gehört als Kostenblock dazu. Eine vermeintlich günstige Lösung ist nicht günstig, wenn qualifizierte Mitarbeiter jede Ausgabe neu aufbauen müssen.

Anbieterabhängigkeit lässt sich technisch begrenzen

Jede Variante erzeugt Abhängigkeiten. Bei einem SaaS-Tool betreffen sie Datenformat, Benutzeroberfläche, Workflows und Vertragsbedingungen. Bei einer Eigenentwicklung entstehen Abhängigkeiten vom Entwicklungsteam, der Architektur und verwendeten Diensten.

Eine tragfähige Softwarearchitektur begrenzt unnötige Bindung durch klare Zuständigkeiten:

• Unternehmensdaten bleiben in führenden Systemen oder kontrollierten Speichern.
• Modellzugriffe laufen über eine gekapselte Komponente.
• strukturierte Ausgaben besitzen ein eigenes, dokumentiertes Schema.
• Prompts und Regeln werden versioniert.
• Evaluationsfälle laufen gegen neue Modell- oder Promptversionen.
• erzeugte Geschäftsvorgänge sind unabhängig vom KI-Anbieter nachvollziehbar.

Vollständige Austauschbarkeit ist kein realistisches Versprechen. Modelle unterscheiden sich bei Werkzeugaufrufen, Kontextgrenzen, Ausgabeformaten und Sicherheitsmechanismen. Eine gute Architektur reduziert den Wechsel auf ein beherrschbares Projekt, statt ihn unmöglich zu machen.

Betrieb und Verantwortung bleiben auch beim Kauf bestehen

Ein fertiges Tool nimmt dem Unternehmen Entwicklung ab, nicht die Verantwortung für seine Nutzung. Jemand muss Nutzer verwalten, Datenfreigaben prüfen, neue Funktionen bewerten und ungeeignete Ergebnisse bearbeiten. Ändert ein Anbieter Modell, Tarif oder Aufbewahrungsregel, braucht es eine fachliche und technische Neubewertung.

Bei einer individuellen Lösung kommen Anwendungsbetrieb, Sicherheitsupdates, Schnittstellenüberwachung und Qualitätsmessung hinzu. Dafür lassen sich Freigaben, Protokolle und Rückfallwege genau auf den Prozess zuschneiden.

Die europäische KI-Verordnung gilt grundsätzlich seit dem 2. August 2026; einzelne Vorschriften besitzen abweichende Anwendungszeitpunkte. Pflichten richten sich unter anderem nach Rolle und Risikoklasse des konkreten Systems. Die DSGVO und weitere Fachregeln gelten daneben weiter. Eine Produktbezeichnung wie „Assistent“ oder „Copilot“ ersetzt diese Einordnung nicht.

Vor der Beschaffung oder Entwicklung sollten deshalb Einsatzbeschreibung, verantwortliche Rolle, erlaubte Nutzer, Datenklassen, menschliche Kontrolle und Abschaltmöglichkeit dokumentiert sein. Bei Anwendungen mit Folgen für Beschäftigte, Kredit, Gesundheit, Sicherheit oder andere sensible Bereiche ist eine spezialisierte rechtliche und fachliche Prüfung notwendig.

Vier typische Entscheidungssituationen

Interne Zusammenfassungen ohne Systemaktion

Mitarbeiter fassen lange interne Dokumente zusammen. Die Quellen werden bewusst hochgeladen, das Ergebnis bleibt ein Entwurf und wird fachlich geprüft. Ein administrierbares Standardtool ist meist ausreichend. Eine eigene Anwendung wird erst interessant, wenn Berechtigungen aus einem DMS automatisch berücksichtigt werden müssen.

Kundenanfragen mit CRM- und Vertragsdaten

Die Antwort benötigt Kundendaten, offenen Auftragsstatus und individuelle Vertragsbedingungen. Jede versendete Aussage wirkt nach außen. Hier passt häufig eine individuelle Integrationsschicht mit Prüfoberfläche: Sie lädt nur erlaubten Kontext, belegt Aussagen und speichert die freigegebene Antwort im CRM. Ein freies Chatfenster würde zu viele manuelle Übergaben erzeugen.

Dokumente auslesen und im ERP verbuchen

Ein vorhandener Dokumentendienst kann OCR und Extraktion liefern. Eigen entwickelt werden Prozesslogik, Stammdatenprüfung, Freigabemaske und ERP-Übergabe. Der Beitrag zur Dokumentenverarbeitung mit KI zeigt, warum diese Kombination oft sinnvoller ist als ein einziges universelles Modell.

Sehr vertrauliche Spezialanwendung ohne geeigneten Cloud-Betrieb

Wenn eine bestätigte Schutzanforderung externe Verarbeitung ausschließt, kommen selbst betriebene Komponenten in Betracht. Vorher muss geprüft werden, ob Datenminimierung, Pseudonymisierung oder ein vertraglich und technisch passender API-Betrieb das Problem bereits lösen. Selbsthosting wird nicht aus einem diffusen Sicherheitsgefühl heraus gewählt, sondern nach dokumentierter Risikoanalyse.

Eine gewichtete Entscheidungsmatrix verhindert Bauchentscheidungen

Die relevanten Kriterien erhalten eine Gewichtung nach ihrer Bedeutung für den konkreten Vorgang. Anschließend werden die real verfügbaren Varianten bewertet. Eine sinnvolle Vorlage enthält:

K.-o.-Kriterien werden vor der Punktwertung festgelegt. Wenn ein Produkt eine zwingende Datenklasse nicht verarbeiten darf oder keine erforderliche Freigabe unterstützt, kann ein günstiger Lizenzpreis diesen Mangel nicht ausgleichen.

Gewichtungen dürfen sich unterscheiden. Für eine interne Formulierungshilfe kann Einführungszeit wichtiger sein als tiefe Integration. Bei einem Assistenten, der Bestellungen vorbereitet, wiegen Nachvollziehbarkeit und Fehlerbehandlung schwerer.

Ein begrenzter Pilot prüft die Entscheidung am echten Prozess

Der Pilot soll nicht beweisen, dass ein Modell Texte erzeugen kann. Er soll die offenen Entscheidungsfragen klären. Dafür wird ein Vorgang mit realistischen, zulässig bereitgestellten Daten durchgespielt.

Ein belastbarer Pilot enthält:

1. festgelegten Start- und Endzustand des Vorgangs
2. repräsentative Testfälle mit erwarteten Ergebnissen
3. einen Kandidaten aus der Standardklasse und gegebenenfalls einen individuellen Prototyp
4. dokumentierte Datenflüsse und Berechtigungen
5. Messung von Qualität, Korrekturaufwand, Laufzeit und variablen Kosten
6. getestete Fehler-, Übergabe- und Abschaltwege

Das Ergebnis ist eine Entscheidungsvorlage. Sie kann lauten: Standardtool einführen, Plattform gezielt integrieren, individuelle Anwendung entwickeln oder Vorhaben stoppen. Ein gestoppter Pilot ist kein Fehlschlag, wenn er eine ungeeignete Investition verhindert.

Das passende Angebot richtet sich nach dem Ergebnis

SW Business Solutions beginnt solche Vorhaben mit Prozess- und Systemanalyse, nicht mit der Vorentscheidung für Eigenentwicklung. Im Rahmen der IT-Beratung vergleichen wir vorhandene Werkzeuge, Datenflüsse, Schnittstellen, Risiken und Gesamtkosten am konkreten Vorgang.

Wenn ein Standardtool fachlich trägt, unterstützen wir bei Konfiguration, Rollenmodell und Integration. Fehlt die passende Prozesslogik, entwickeln wir eine kontrollierte Anwendung mit eigener Oberfläche, Backend, Prüfregeln und Anbindung an CRM, ERP oder Fachsoftware. Unsere Leistung KI-Integration und LLM-Entwicklung umfasst dabei auch Evaluationsfälle, Modellzugriffe, Monitoring und einen definierten menschlichen Freigabeweg.

Das gewünschte Ergebnis ist weder „möglichst viel KI“ noch eine weitere isolierte Software. Mitarbeiter sollen einen vollständigen Vorgang in einem verlässlichen System bearbeiten können: benötigte Informationen liegen vor, der KI-Vorschlag ist prüfbar und die freigegebene Aktion landet im richtigen Unternehmenssystem.

Als nächster Schritt genügt ein klar abgegrenzter Vorgang. Erfassen Sie fünf typische Fälle, zwei schwierige Fälle, die benötigten Datenquellen und die Folge eines Fehlers. Damit lässt sich in einem strukturierten Termin belastbar entscheiden, ob ein fertiges KI-Tool reicht, eine Integration fehlt oder eine eigene KI-Anwendung wirtschaftlich sinnvoll ist.