Mit KI gebaut. Aber schon bereit für Ihren Betrieb?

Ein Prototyp beantwortet vor allem eine fachliche Frage, nämlich ob dieser Ablauf bei Ihrem Problem hilft. Sie können ihn zeigen, ausprobieren und mit dem Team besprechen. Das ist oft verständlicher als eine lange Liste abstrakter Anforderungen. Welche Felder fehlen? Welche Ansicht ist nützlich? Wo wird heute doppelt gearbeitet?

Für den echten Betrieb stellen sich andere Fragen. Was passiert bei einer unterbrochenen Verbindung? Kann jemand versehentlich Daten eines anderen Kunden sehen? Wer bemerkt einen Fehler? Und wie kommen Sie wieder an Ihre Daten, wenn etwas ausfällt?

Daran ändert die KI-Unterstützung nichts. Das BSI und die französische Sicherheitsbehörde ANSSI beschreiben Chancen von Programmierassistenten und auch Risiken, etwa vertrauliche Eingaben und Sicherheitslücken im erzeugten Code. Schnell erzeugter Code ist deshalb der Anfang einer Prüfung und ersetzt sie nicht.

Ein häufiger Denkfehler geht so: Sieht eine Mitarbeiterin keinen Löschknopf, darf sie auch nichts löschen. Die Anwendung muss die Berechtigung aber dort prüfen, wo die Daten gelesen oder verändert werden. Die Oberfläche allein schützt den Vorgang nicht.

Legen Sie deshalb zuerst verständliche Rollen fest. Darf das Büro alle Aufträge sehen? Darf die Werkstatt Preise ändern? Wer verwaltet die Benutzer? Die Regeln müssen zu Ihrem Betrieb passen und mit echten Tests überprüft werden. „Alle haben denselben Zugang“ ist bequem, macht es aber schwer, Verantwortung zuzuordnen und Rechte gezielt zu vergeben.

Prüfen Sie auch die Zugangsschlüssel zu anderen Diensten. Ein geheimer Schlüssel darf nicht in einer Datei landen, die jeder Besucher herunterladen kann. Bevor die Anwendung mit echten Daten arbeitet, sollte klar sein, welche Informationen wohin übertragen werden und wer darauf zugreifen kann.

Bei einer Anwendung, die Angebote berechnet, nützt der schönste Bildschirm wenig, wenn ein Rabatt falsch angewendet wird oder die Rundung nicht zu Ihrer Rechnung passt. In einer schnellen Vorführung fällt so etwas nicht unbedingt auf.

Beginnen Sie mit den Regeln, auf die Ihr Betrieb angewiesen ist. Sammeln Sie normale Fälle und bewusst schwierige Beispiele: fehlende Angaben, doppelte Eingaben, ungültige Werte oder zwei Personen, die denselben Auftrag bearbeiten. Die erwarteten Ergebnisse legt Ihr Betrieb fest und nicht der KI-Assistent.

Automatisierte Tests helfen, diese Regeln bei jeder Änderung erneut zu prüfen. Die fachliche Abnahme brauchen Sie trotzdem, denn die Tests ersetzen die Erfahrung aus dem Betrieb nicht. Jemand, der den Ablauf wirklich kennt, muss beurteilen, ob die Software den Alltag richtig abbildet.

Mit „läuft in der Cloud“ ist der Betrieb noch nicht entschieden. Sie sollten wissen, welche Daten gespeichert werden, welche Dienste beteiligt sind, welche Zugriffe bestehen und wie eine Wiederherstellung funktioniert. Auf Wunsch kann eine passende Lösung auch auf Ihrem eigenen Server im Büro oder in einem deutschen Rechenzentrum laufen. Wo sie läuft, entscheiden Ihre Anforderungen und kein Schlagwort.

Ein Backup hilft erst, wenn es sich wiederherstellen lässt. Deshalb gehört ein Wiederherstellungstest zum Plan. Klären Sie auch, wie viel Datenverlust oder Ausfallzeit Ihr Betrieb verkraften könnte. Danach richten sich die Sicherungs- und Betriebsmaßnahmen.

Sicher bleibt die Anwendung nach dem Start nicht von allein. Abhängigkeiten und Betriebssysteme brauchen Updates, und Fehler und neue Anforderungen muss jemand einordnen. Dafür sollte es eine benannte Person oder einen Dienstleister geben, der die Warnungen erhält und weiß, was zu tun ist.

Eine seriöse Bewertung trennt die Idee vom Zustand des Codes. Vielleicht ist die Oberfläche schon gut und die Datenstruktur brauchbar, und es fehlt nur ein sauberer Zugriffsschutz. Es kann aber auch sein, dass zentrale Teile so eng verwoben sind, dass eine gezielte Neuimplementierung weniger Risiko schafft als viele kleine Reparaturen.

Diese Entscheidung braucht einen Befund. Wir gehen zuerst die wichtigsten Abläufe durch, prüfen die technische Struktur und legen fest, welche offenen Risiken zuerst drankommen. Danach lässt sich ein klarer Umfang vereinbaren. Was muss vor dem Start erledigt sein, was kann später kommen, und was wird bewusst nicht übernommen?

Der Prototyp bleibt dabei der gemeinsame Bezugspunkt und hilft, nicht am eigentlichen Bedarf vorbeizuplanen. Am Ende soll ein Werkzeug stehen, das Ihre Leute verstehen und auf das sie sich verlassen können.

Ein begrenzter Pilot mit ausgewählten Mitarbeitenden zeigt, ob der Ablauf unter echten Bedingungen trägt. Legen Sie vorher fest, woran Sie einen erfolgreichen Start erkennen und wann Sie zum bisherigen Verfahren zurückkehren würden. Ein Rückfallplan ist gute Vorbereitung und kein Zeichen von Misstrauen.

Achten Sie im Pilot neben der Bedienung auf Fehlermeldungen, Datenqualität und die Übergabe an andere Programme. Halten Sie Rückmeldungen fest und beheben Sie kritische Probleme, bevor weitere Nutzer dazukommen.

Zum Abschluss gehören Quellcode, dokumentierte Zugänge, eine nachvollziehbare Bereitstellung und eine kurze Einweisung, damit aus dem schnellen Prototyp nicht die nächste Anwendung wird, die nur eine einzige Person versteht.