Interne Tools mit KI selbst bauen: Chancen und Grenzen

Wann lohnt es sich, ein internes Tool mit KI selbst zu bauen?

Ein internes Tool lohnt sich als Selbstbau, solange eine Person den Ablauf vollständig versteht, wenige Kolleginnen und Kollegen betroffen sind, keine sensiblen Daten verarbeitet werden und ein Ausfall niemanden ernsthaft blockiert. Genau in diesem Rahmen sind KI-Programmierassistenten und No-Code-Baukästen heute wirklich gut: Ein Prototyp, eine persönliche Auswertung oder ein kleiner interner Helfer entsteht in Stunden statt Wochen. Sobald mehrere Personen darauf angewiesen sind, echte Kundendaten hineinfließen oder das Tool von außen erreichbar wird, ändert sich die Rechnung deutlich.

Dieser Beitrag trennt beide Fälle: Was funktioniert gut, wo kippt es, und woran du erkennst, dass ein Profi dazugehört.

Was mit KI-Selbstbau heute wirklich gut funktioniert

Für einen klar begrenzten Kreis von Aufgaben ist der Selbstbau die richtige Wahl:

• Persönliche Auswertungen und Helfer. Eine Tabelle sortieren, eine Zusammenfassung erzeugen, einen wiederkehrenden Textbaustein automatisieren. Das Risiko trägt nur die bauende Person selbst.
• Prototypen für eine Idee. Bevor du ein Projekt beauftragst, zeigt ein selbst gebauter Prototyp, ob die Idee im Alltag überhaupt trägt. Fehler kosten hier wenig, weil noch niemand darauf angewiesen ist.
• Ein-Personen-Werkzeuge ohne fremde Daten. Ein internes Notizsystem oder ein persönlicher Planer, den nur du nutzt und pflegst, bleibt überschaubar, solange keine dritte Person betroffen ist.

In all diesen Fällen ist die KI ein Beschleuniger für etwas, das ohnehin in deiner eigenen Verantwortung bleibt. Genau diese Logik gilt übrigens auch beim Webdesign: KI kann eine erste Struktur oder einen Entwurf schnell liefern, ersetzt aber nicht die Entscheidungen dahinter, sobald daraus etwas Verbindliches wird. Wir haben das ausführlicher in Professionelles Webdesign trotz KI: Warum? beschrieben, das Muster überträgt sich eins zu eins auf interne Tools.

Wo es kippt: fünf Stellen, an denen ein Selbstbau zum Risiko wird

1. Zugriffsrechte

Ein selbst gebautes Tool hat selten ein durchdachtes Rechtekonzept. Häufig sehen alle Nutzenden alle Daten, weil eine feingranulare Rechteverwaltung mehr Aufwand macht als die eigentliche Funktion. Das reicht für ein persönliches Werkzeug. Sobald unterschiedliche Rollen unterschiedliche Ausschnitte sehen sollten, etwa bei Kundendaten oder Gehaltsinformationen, wird eine fehlende Rechtetrennung schnell zum echten Problem.

2. Datenschutz

Sobald personenbezogene Daten verarbeitet werden, gilt die DSGVO unabhängig davon, wer das Tool gebaut hat. Ein selbst gebautes Werkzeug ersetzt kein Verzeichnis von Verarbeitungstätigkeiten, keine Rechtsgrundlage und keinen Auftragsverarbeitungsvertrag mit dem eingesetzten KI-Anbieter, falls Daten dorthin übertragen werden. Art. 32 der DSGVO (Verordnung (EU) 2016/679) verlangt technische und organisatorische Maßnahmen, die dem Risiko der Verarbeitung angemessen sind. Der vollständige Verordnungstext steht bei EUR-Lex. Das ist keine Rechtsberatung, sondern eine Orientierung: Ob dein konkretes Tool diese Anforderungen erfüllt, muss im Einzelfall geprüft werden, im Zweifel mit deinem Datenschutzbeauftragten.

3. Wartung, wenn die bauende Person geht

Ein Tool, das nur eine Person versteht, ist ein Wissensrisiko. Fällt diese Person aus, weil sie Urlaub macht, krank wird oder das Unternehmen verlässt, bleibt oft niemand zurück, der eine Änderung sicher vornehmen kann. Frag dich schon beim Bauen: Wer könnte in sechs Wochen eine kleine Anpassung machen, ohne dich zu fragen?

4. Backups

Selbst gebaute Tools laufen häufig ohne geplante Sicherung, weil das Backup in einem schnellen Prototyp nicht mitgedacht wird. Eine Sicherung, die nie getestet wurde, ist im Ernstfall keine Sicherung. Wenn das Tool wichtige Daten verwaltet, die es sonst nirgendwo gibt, gehört eine geprüfte Wiederherstellung zur Grundausstattung, nicht zur Kür.

5. Sicherheit exponierter Endpunkte

Sobald ein Tool von außen erreichbar ist, etwa über ein Formular, eine öffentliche URL oder eine Schnittstelle, ändert sich die Risikolage grundlegend. Ein KI-Assistent kann funktionierenden Code schreiben, ohne automatisch an Authentifizierung, Rate-Limits, Eingabevalidierung oder Protokollierung zu denken. Eine ungeschützte Schnittstelle ist dann nicht nur ein internes Problem, sondern ein Angriffspunkt für Dritte.

Selbstbau, Standard-Werkzeug oder Profi: der Vergleich

Die Tabelle zeigt keine feste Grenze in Zeilenzahl oder Nutzerzahl. Sie zeigt, dass mit jeder Stufe eine zusätzliche Verantwortung dazukommt, die ein schneller Prototyp selten von allein mitbringt.

Checkliste: Wann du einen Profi dazuholen solltest

Wenn mindestens einer dieser Punkte zutrifft, lohnt sich ein zweiter Blick von außen:

• Mehr als eine Handvoll Personen nutzen das Tool täglich in ihrer eigentlichen Arbeit.
• Kunden-, Personal- oder andere personenbezogene Daten sind beteiligt.
• Das Tool ist ohne Login von außen erreichbar.
• Niemand außer dir kann Code, Automatisierung oder Datenbank verstehen und ändern.
• Es gibt keine Sicherung, oder du hast eine Wiederherstellung noch nie getestet.
• Ein Ausfall würde Rechnungen, Fristen, Zahlungen oder Kundentermine gefährden.
• Du müsstest Zugänge und Wissen erst aufwendig übergeben, um selbst eine Pause machen zu können.

Keiner dieser Punkte bedeutet, dass das Tool sofort abgeschaltet werden muss. Er bedeutet, dass die Frage nach Zugriffsrechten, Datenschutz, Wartung, Backup und Absicherung jetzt beantwortet werden sollte, bevor ein Ausfall sie erzwingt. Wie du einen begrenzten KI-Anwendungsfall von Anfang an sauber abgrenzt, beschreiben wir im Beitrag KI-Projekt im Unternehmen sicher einführen.

Governance schlägt Verbot

Ein internes Tool zu verbieten, löst das eigentliche Problem selten. Mitarbeitende bauen dann oft trotzdem etwas, nur ohne Rückmeldung und ohne Übersicht darüber, was inzwischen im Umlauf ist. Sinnvoller ist eine kurze, gelebte Regel: Welche Werkzeuge sind für welche Datenklasse erlaubt, wer prüft ein neues Tool, bevor es Kundendaten sieht, und wo landet die Übersicht, damit niemand ein vergessenes Tool Monate später wiederfindet. Diese Regel muss kein langes Dokument sein: eine Seite mit erlaubten Werkzeugen, Datenklassen und einer verantwortlichen Person reicht für den Anfang.

Wann sich der Weg zu n3tz lohnt

Ein selbst gebautes Tool ist kein Fehler, sondern oft der ehrlichste Beweis dafür, dass ein Ablauf im Betrieb wirklich gebraucht wird. Die Frage ist nur, ab wann die Verantwortung größer ist als das, was eine einzelne Person nebenbei tragen kann. Genau an diesem Punkt beginnt unsere Arbeit: Leistungen für Software, Integration und Prozessoptimierung reichen von einer Absicherung eines bestehenden Prototyps bis zu einer sauber betriebenen eigenen Anwendung. Wir bauen dabei nicht automatisch neu, sondern schauen zuerst, was von deinem Selbstbau bleiben kann und was einen professionellen Rahmen braucht.

Selbst gebautes Tool absichern lassen oder sauber neu aufsetzen: Vorhaben mit n3tz besprechen →