Interne Tools entwickeln: selbst bauen oder beauftragen?

Was ist ein internes Tool, und wer sollte es bauen?

Ein internes Tool ist eine kleine Anwendung, die nur dein Team benutzt: eine Übersicht offener Aufträge, ein Formular für Materialbestellungen oder eine Auswertung aus zwei Systemen. Selbst bauen, heute oft mit KI-Programmierassistenten oder No-Code-Baukästen, passt, 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. Gibt es für deinen Ablauf eine verbreitete Standardsoftware, ist sie meist die bessere Wahl, weil Rollen, Sicherung und Support schon mitkommen. Professionelle Entwicklung lohnt sich, wenn mehrere Personen täglich darauf angewiesen sind, Kunden- oder Personaldaten hineinfließen, das Tool von außen erreichbar ist oder es an vorhandene Systeme angebunden werden muss.

Im ersten Fall sind KI-Werkzeuge heute wirklich gut: Ein Prototyp, eine persönliche Auswertung oder ein kleiner interner Helfer entsteht in Stunden statt Wochen. Sobald das Tool aber zur gemeinsamen Arbeitsgrundlage wird, ändert sich die Rechnung deutlich.

Dieser Beitrag trennt die Fälle: Was funktioniert gut, wo kippt es, wie sieht das an einem durchgespielten Beispiel aus, 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.

Beispiel (illustrativ): vom Bestellzettel zum Team-Tool

Das folgende Beispiel ist ausgedacht, aber typisch. Es ist kein n3tz-Kundenprojekt.

• Ablauf: In einem Handwerksbetrieb bestellen die Monteure Material per Zuruf oder Messenger. Das Büro sammelt alles auf einem Zettel und bestellt einmal am Tag beim Großhändler. Rückfragen und doppelte Bestellungen kosten jeden Tag Zeit.
• Eingaben: Wer bestellt, für welche Baustelle oder Auftragsnummer, welcher Artikel, welche Menge, bis wann. Die Artikelliste kommt als Export aus der vorhandenen Warenwirtschaft.
• Berechtigungen: Monteure legen Bestellungen an und sehen nur ihre eigenen. Das Büro sieht alle, fasst sie zusammen und setzt den Status. Die Geschäftsführung sieht eine Monatsübersicht pro Baustelle. Ohne Login erreicht niemand das Tool.
• Ergebnis: Ein Formular auf dem Handy, eine Tagesliste fürs Büro mit den Zuständen offen, bestellt und geliefert, und eine Übersicht der Materialkosten pro Baustelle.

Als Prototyp kann die Bürokraft so etwas mit einem KI-Werkzeug schnell zusammenbauen und mit zwei Monteuren testen. Das ist ein guter Test, ob der Ablauf trägt. Sobald alle Monteure es täglich nutzen und die Bestellungen an Auftragsnummern hängen, gehören Login, Rollen, Sicherung und eine verantwortliche Person dazu. Dann lohnt es sich, den Prototyp prüfen zu lassen oder sauber neu aufzusetzen. Vorher steht eine einfache Frage: Kann die Handwerkersoftware, die ihr schon nutzt, Bestellungen bereits abbilden? Dann ist das Einrichten dort meist günstiger als jedes eigene Tool.

Lebt dein Ablauf heute in einer geteilten Tabelle, hilft der Beitrag Excel-Liste ablösen: Wann sich eine eigene App lohnt bei derselben Entscheidung, mit einem Vorher-nachher-Beispiel und den Schritten für die Umstellung.

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: Wir gehen einen echten Ablauf mit dir durch, schauen uns deinen Selbstbau an und klären, was davon bleiben kann und was einen professionellen Rahmen braucht. Wir bauen dabei nicht automatisch neu. Was wir übernehmen können, von der Absicherung eines bestehenden Prototyps bis zu einer sauber betriebenen eigenen Anwendung, beschreiben unsere Leistungen für Software, Integration und Prozessoptimierung.

Einen echten Ablauf mit uns durchgehen: Tool oder Prototyp mit n3tz besprechen