Lokale KI für Unternehmen: Voraussetzungen und Entscheidungscheck

Was soll die lokale KI im Unternehmen erledigen?

Beginne mit einer Aufgabe, die dein Team heute tatsächlich bearbeitet: freigegebene Anleitungen finden, wiederkehrende Fragen beantworten oder ein telefonisches Anliegen strukturiert aufnehmen. Beschreibe Eingang, gewünschtes Ergebnis und den Fall, in dem ein Mensch übernehmen muss. „Wir brauchen lokale KI“ allein sagt noch nicht, welches System sinnvoll ist.

Ein möglicher Telefonprozess lautet: Eine Störungsmeldung entgegennehmen, Gerät und Rückrufkontakt erfassen und das Anliegen an den Support übergeben. Ob die Meldung anschließend ein Ticket erzeugen darf, hängt von der angebundenen Schnittstelle und den freigegebenen Aktionen ab. Das ist ein Planungsbeispiel, kein berichtetes Kundenergebnis.

Trenne zwei Entscheidungen: Soll der Arbeitsablauf KI verwenden? Und wo sollen seine Komponenten laufen? Ein lokal betriebenes Modell macht einen ungeklärten Prozess nicht automatisch brauchbar. Ein kleiner Pilot sollte zuerst zeigen, ob das Ergebnis den Mitarbeitenden bei ihrer Arbeit hilft.

„Lokal“ braucht einen überprüfbaren Datenpfad

Schreibe für jede Komponente auf, wer sie betreibt, welche Daten sie erhält und wohin sie Verbindungen aufbaut. Modell, Dokumentensuche, Anwendung und Protokolle können unterschiedliche Betriebsorte haben. Ein lokales Sprachmodell allein belegt daher keinen vollständig lokalen Ablauf.

Ein öffentlich dokumentiertes Beispiel ist der RAG-Chatbot der RTR. Die RTR beschreibt unter anderem ihre lokal betriebenen Sprach- und Embedding-Modelle und die Suche in ihrem Dokumentenbestand. Das zeigt eine konkrete Architektur für diese Anwendung; daraus lässt sich keine allgemeine Leistungs- oder Produktzusage für andere Systeme ableiten.

Bei personenbezogenen Daten bleiben Zweck, Berechtigungen und Sicherheitsmaßnahmen Teil der Prüfung. Die DSGVO behandelt unter anderem Auftragsverarbeitung in Artikel 28 und Sicherheit in Artikel 32. Der Standort eines Servers beantwortet diese Fragen nicht allein.

• Eingang: Welche Texte, Dokumente oder Audiodaten gelangen in das System?
• Verarbeitung: Wo laufen Sprachmodell, Suche und gegebenenfalls Spracherkennung und Sprachausgabe?
• Speicherung: Wo liegen Originaldokumente, Suchindex, Gesprächsdaten und Protokolle?
• Verbindungen: Welche Dienste werden für Telefonie, E-Mail, Updates, Support und Integrationen benötigt?
• Zugriff: Wer kann Daten lesen, ändern, exportieren oder löschen?

Entscheidungsmatrix: selbst betreiben oder betreut nutzen?

Die Tabelle ist eine Arbeitshilfe für dein Projekt. Trage auf beiden Seiten konkrete Antworten und Nachweise ein. Ein ungeklärter Punkt bleibt offen; er wird nicht durch einen pauschalen Punktwert ersetzt.

Kosten vergleichen: dieselbe Aufgabe, derselbe Zeitraum

Eine Hardwarebestellung und ein monatliches Serviceangebot lassen sich erst vergleichen, wenn beide dieselbe Aufgabe abdecken. Verwende einen gemeinsam festgelegten Betrachtungszeitraum. Halte einmalige und laufende Aufwände getrennt fest; schätze Betriebsstunden offen, statt sie mit null anzusetzen.

Zum eigenen Betrieb gehören in der Kalkulation beispielsweise Beschaffung oder Miete, Einrichtung, Strom, Speicher, Sicherungen, Wartung und Arbeitszeit. Bei einem betreuten Angebot gehören Einrichtung, Nutzung, enthaltene Leistungen, Zusatzdienste und interne Betreuung in dieselbe Gegenüberstellung. Für beide Varianten sind Telefonie und Fachsysteme anhand des konkreten Angebots zu berücksichtigen.

Diese Kostenstruktur ist eine Planungsmethode. Sie enthält keine allgemeine Amortisationsdauer oder Aussage, dass eine Betriebsform immer günstiger sei. Nutze den Hardware-Leitfaden, um den technischen Teil der Annahmen vorzubereiten.

Wer übernimmt den Betrieb?

Ordne Aufgaben einer verantwortlichen Stelle zu, bevor das System produktiv arbeitet. „Das macht die IT“ ist zu ungenau, wenn Anwendung, Infrastruktur und Fachprozess bei unterschiedlichen Teams liegen.

Für jede Aufgabe helfen vier Angaben: verantwortliche Person oder Rolle, Vertretung, Auslöser und Nachweis der Durchführung. So lässt sich beispielsweise eine Sicherung von einem tatsächlich geprüften Wiederanlauf unterscheiden.

• Fachbereich: Inhalte freigeben und fachliche Fehler beurteilen.
• IT beziehungsweise Betriebspartner: Infrastruktur, Zugriff und Kapazität betreuen.
• Anwendungsverantwortliche: Versionen, Konfiguration und Integrationen prüfen.
• Support: Störungen annehmen, Zuständigkeit klären und Eskalation auslösen.
• Projektleitung: Wartung, Wiederherstellung und Übergabe vor dem Start abnehmen.

Was muss der Pilot nachweisen?

Lege Beispiele und erwartetes Verhalten vor dem Test fest. Dokumentiere für jeden Fall Eingabe, berechtigte Datenquelle, erwartete Aktion, tatsächliche Ausgabe und Bewertung. Damit wird nachvollziehbar, was funktioniert hat und was noch geändert werden muss.

Teste neben dem üblichen Ablauf auch fehlendes Wissen, widersprüchliche Dokumentstände, nicht erreichbare Zielsysteme und Übergaben an Menschen. Antwortqualität, Laufzeit und Betriebsfähigkeit sind getrennte Prüfpunkte. Eine gelungene Einzelvorführung beantwortet noch nicht alle drei.

Für Dokumentenfragen zeigt der Leitfaden zu lokaler KI mit eigenen Daten, wie ein kleiner Fragenkatalog aussehen kann. Für Kapazitätstests hältst du Konfiguration, Lastprofil und gemessene Antwortzeiten zusammen fest.

• Arbeitsablauf und ausgeschlossene Aufgaben schriftlich abgegrenzt.
• Datenpfad und erlaubte Verbindungen für die Zielumgebung dokumentiert.
• Abnahmekriterien einschließlich Fehler- und Übergabefällen vor dem Test vereinbart.
• Betriebsaufgaben, Supportweg und Wiederherstellung zugeordnet.
• Offene Punkte mit Verantwortlichen und nächstem Prüfschritt versehen.

Einordnung für smao On Premises

smao On Premises ist eine Betriebsoption für KI-Telefonassistenz. Die aktuelle Referenzbereitstellung nutzt kundeneigene Linux- und Docker-Infrastruktur. KI-Dienste und Produktdaten können in der Kundenumgebung laufen; Telefonie, externe Verbindungen und Betriebsverantwortung werden für das Projekt vereinbart.

Die Anwendung allein enthält nicht automatisch die vollständige Telefonie-Anbindung. Gateway, Telefonanlage, Netzwerkpfade und benötigte Integrationen müssen zur Zielumgebung passen und abgenommen werden. Eine pauschale Funktionsgleichheit mit der Cloud oder ein Betrieb ohne jede externe Verbindung wird daraus nicht abgeleitet.

Für ein erstes Gespräch genügen der gewünschte Telefonablauf, die vorhandene Infrastruktur, erwartete Last und offene IT-Anforderungen. Die Architekturseite ordnet Datenpfade und Prüfunterlagen ein.

Grundlage dieses Leitfadens

Der Beitrag verbindet verlinkte Primärquellen mit dokumentierten smao Produktgrenzen. Entscheidungsmatrix, Kostenstruktur und Checklisten sind redaktionelle Arbeitshilfen. Sie enthalten keine gemessenen Einsparungen, Kundenkennzahlen oder Hardware-Benchmarks. Technische und vertragliche Zusagen entstehen erst für die geprüfte Zielumgebung.