Fachabteilungen programmieren mit KI-Agenten: was die IT jetzt leisten muss

Coding Agents machen eigene Software für Personalabteilung, Vertrieb und Controlling erschwinglich. Wer die Anwendungen prüft, betreibt und verantwortet, ist damit noch lange nicht geklärt.

Die Personalabteilung braucht ein Werkzeug für die jährlichen Beurteilungsgespräche: Termine planen, Feedback einsammeln, alles zu einer Übersicht zusammenführen. Früher hieß das Antrag an die IT, Warteschlange, vielleicht ein Projekt im nächsten Jahr. Heute beschreibt die Abteilung ihr Anliegen einem KI-Agenten und baut die Anwendung selbst.

Genau dieses Beispiel steht in einer Kundenfallstudie von OpenAI, die am 5. November 2026 erschienen ist. Beim indischen Fitnessunternehmen cult.fit haben nach Angaben von OpenAI Teams außerhalb der Softwareentwicklung in den vergangenen Monaten mehr als 20 interne Anwendungen mit dem Coding Agent Codex gebaut, darunter einen Workflow der Personalabteilung für Leistungsbeurteilungen.

Für IT-Leitungen in deutschen Unternehmen klingt das nach Entlastung und nach Kontrollverlust zugleich. Beides trifft zu. Die Fallstudie ist Werbung eines Herstellers für sein Produkt, ihre Zahlen hat niemand unabhängig geprüft. Lesenswert ist sie trotzdem, vor allem wegen dessen, was sie nebenbei über die Voraussetzungen verrät, und wegen dessen, was sie weglässt. Meine Einschätzung vorweg: Die IT wird nicht überflüssig. Sie hört auf, jede Anwendung selbst zu bauen, und wird zu der Stelle, die Plattform, Leitplanken, Freigaben und Befähigung liefert.

Was die Fallstudie zeigt und was sie offenlässt

Coding Agents sind KI-Werkzeuge, die nicht nur Code vorschlagen, sondern selbstständig Dateien anlegen, Programme ausführen, Fehler suchen und Änderungen vornehmen. Bekannte Vertreter sind Codex von OpenAI, Claude Code von Anthropic und der Cloud-Agent von GitHub Copilot (bis Frühjahr 2026 „Coding Agent“); Microsoft bietet in seiner Low-Code-Plattform Power Apps den Assistenten Copilot in Power Apps an. Der Unterschied zu früheren Assistenten: Man beschreibt das Ziel, der Agent erledigt die Zwischenschritte.

Bei cult.fit stand am Anfang laut Fallstudie nicht die Fachabteilung, sondern die eigene Entwicklung. Sie wechselte zuerst von einem Mix verschiedener KI-Assistenten auf ein gemeinsames Werkzeug; seitdem folgen die Strukturen der Code-Ablagen (Repositories), Tests und Code-Reviews gemeinsamen Konventionen. Wo Agenten im Engineering Fehler beheben oder Funktionen umsetzen, legen sie ihre Änderungen als Vorschlag (Pull Request) vor, den ein Ingenieur prüft. Erst danach öffnete das Unternehmen den Zugang für andere Bereiche. Unternehmensdaten wurden so aufbereitet, dass Fachbereiche Routineauswertungen selbst erstellen können, die vorher über ein zentrales Analystenteam liefen. Dazu kamen nach Angaben von OpenAI ein großer Hackathon und eine eintägige Session, in der das Management etwas für die eigene Arbeit baute. Außerdem bietet die Entwicklung zweimal pro Woche Sprechstunden an, um Projekte von der Idee in die Produktion zu bringen, und in ausgewählten Bereichen arbeiten Ingenieure direkt mit.

Die auffälligste Zahl betrifft ein Dashboard. Nachdem die Kosten für die bisher genutzte Dashboard-Software stark gestiegen waren, hat ein Ingenieur deren Funktionen laut Fallstudie an einem Wochenende mit Codex nachgebaut. Cult.fit betreibt sie jetzt in einer eigenen Anwendung und vermeidet damit nach eigenen Angaben mehr als 100.000 US-Dollar Softwarekosten im Jahr. Zwei Dinge gehen in der Begeisterung leicht unter. Erstens hat diesen Nachbau ein Ingenieur erstellt, nicht eine Fachabteilung. Zweitens ist die Rechnung nicht offengelegt: Kosten für Betrieb, Wartung und die Lizenzen des KI-Werkzeugs selbst tauchen in den veröffentlichten Angaben nicht auf.

Und dann die eigentliche Lücke. Die Fallstudie beschreibt Unterstützung auf dem Weg von der Idee in die Produktion, aber kein Freigabeverfahren und keine Sicherheits- oder Datenschutzprüfung für die mehr als 20 Anwendungen der Fachabteilungen. Die Prüfung durch Ingenieure erwähnt sie nur für die Agenten im Engineering. Offen bleibt auch, wer die Apps betreibt und wartet, wer einsteht, wenn eine davon falsche Zahlen liefert, und was mit den Personaldaten im Beurteilungs-Workflow geschieht. Genau an dieser Stelle beginnt die Arbeit der IT.

Warum interne Werkzeuge plötzlich billig wirken

Interne Werkzeuge waren schon immer das Stiefkind der Softwareentwicklung. Eine Urlaubsübersicht für 40 Leute, ein Formular für Reisekosten, eine Auswertung der Hotline-Tickets: zu klein für ein Projekt, zu speziell für Standardsoftware. Also entstanden Excel-Listen mit Makros, Access-Datenbanken und E-Mail-Schleifen.

Coding Agents verschieben diese Rechnung. Der erste lauffähige Entwurf einer kleinen Web-Anwendung kann heute in Stunden statt in Wochen entstehen. Wer sein Fachproblem genau beschreiben kann, kommt erstaunlich weit, auch ohne Programmierkenntnisse. Der Begriff „Vibe Coding“, den der KI-Forscher Andrej Karpathy im Februar 2025 prägte, beschreibt die extreme Form dieser Arbeitsweise: Man gibt der KI Anweisungen und schaut sich den Code kaum noch an.

Billig ist allerdings nur der Anfang. Was eine Anwendung kostet, entscheidet sich nicht beim ersten Entwurf, sondern in den Jahren danach, dazu weiter unten mehr. Wer zuerst die Grundsatzfrage zwischen klassischer Programmierung und Baukästen ohne Code klären möchte, findet sie im Beitrag To code or no code: das ist hier die Frage. Hier geht es um die organisatorische Seite.

Schatten-IT, diesmal mit echtem Code

Neu ist das Phänomen nicht. Fachabteilungen haben sich schon immer selbst geholfen, wenn die IT keine Zeit hatte. Das Excel-Makro, das nur noch eine einzige Person versteht, kennen viele Unternehmen. Schatten-IT nennt man Systeme, die ohne Wissen oder Freigabe der IT entstehen.

Zwei Dinge unterscheiden die neue Generation. Erstens entsteht echter Code: Web-Anwendungen mit Datenbank, Anmeldung und Schnittstellen zu anderen Systemen. Zweitens wächst die Reichweite. Ein Makro lag auf einem Laufwerk; eine Web-Anwendung ist mit einem Klick für die ganze Firma erreichbar, im schlimmsten Fall für das ganze Internet. OpenAI erprobt etwa unter dem Namen „Sites“ eine Funktion, mit der sich Apps und Dashboards direkt aus ChatGPT oder Codex heraus veröffentlichen und hosten lassen, derzeit als öffentliche Beta und je nach Plan, Region und Einstellungen des Arbeitsbereichs.

Wie groß der Abstand zwischen Praxis und Regeln in Deutschland ist, zeigt eine Bitkom-Umfrage unter 604 Unternehmen aus dem Sommer 2025. 8 Prozent sagen, private KI-Werkzeuge seien bei ihren Beschäftigten weit verbreitet, 17 Prozent kennen Einzelfälle, weitere 17 Prozent vermuten es. Regeln für den Einsatz von KI-Werkzeugen haben nur 23 Prozent der Unternehmen. Die Umfrage betrifft KI-Nutzung allgemein, nicht das Programmieren, aber das Muster ist dasselbe.

Ein Verbot allein hilft erfahrungsgemäß wenig. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) und die französische Cybersicherheitsbehörde ANSSI empfehlen in ihrem gemeinsamen Papier zu KI-Programmierassistenten deshalb beides: unkontrollierte Zugänge über private Konten für die Softwareentwicklung im Unternehmen zu untersagen und zugleich legitime Angebote mit klaren Nutzungsregeln zu schaffen, vorzugsweise sicher konfigurierte Unternehmenskonten. So lässt sich die Schatten-IT verringern.

Die neue Rolle der IT: Plattform statt Projektliste

Wenn Fachabteilungen bauen, verlagert sich die Arbeit der IT nach vorn und nach hinten. Sie stellt den Rahmen bereit, in dem gebaut wird, und sie prüft, bevor etwas breit genutzt wird. Konkret heißt das:

• Eine gemeinsame Plattform: ein freigegebenes Werkzeug mit Unternehmenskonto statt privater Zugänge, ein zentraler Ort für den Code und eine Umgebung, in der die Anwendungen laufen. Wer zehn Werkzeuge in zehn Abteilungen duldet, kann keines davon überblicken.
• Anmeldung und Berechtigungen aus einer Hand: Keine App baut ihre eigene Benutzerverwaltung. Sie hängt an der zentralen Anmeldung des Unternehmens, Rollen und Rechte kommen aus dem Verzeichnisdienst. Scheidet jemand aus, verliert er den Zugriff überall zugleich.
• Daten nur über freigegebene Schnittstellen: Die Personal-App greift nicht direkt auf die Datenbank des Lohnsystems zu, sondern auf eine Schnittstelle, die nur die nötigen Felder liefert, möglichst nur lesend und mit Protokoll. Auch bei cult.fit war die Aufbereitung der Daten offenbar ein Kern des Vorhabens.
• Vorlagen: ein Startgerüst mit Anmeldung, Protokollierung, Tests und schriftlichen Hinweisen für den KI-Agenten. Agenten orientieren sich stark an dem, was sie im Projekt vorfinden. Eine gute Vorlage ist deshalb eine der wirksamsten Leitplanken.
• Zentrale Einstellungen der Werkzeuge: Die gängigen Agenten lassen sich vom Unternehmen steuern. Bei Codex ist die Cloud-Variante in Enterprise-Arbeitsbereichen standardmäßig ausgeschaltet, und der Netzwerkzugriff des Agenten muss ausdrücklich erlaubt werden. Claude Code kennt verwaltete Einstellungen, die einzelne Nutzer nicht überschreiben können. Der Cloud-Agent von GitHub Copilot darf jeweils nur auf einen einzigen Zweig schreiben und Pull Requests weder freigeben noch zusammenführen; vor dem Zusammenführen ist eine menschliche Prüfung vorgeschrieben. In der Power Platform legen Datenrichtlinien fest, welche Anschlüsse an andere Dienste (Konnektoren) gemeinsam verwendet werden dürfen.

Das ist kein Werkzeugvergleich, sondern ein Hinweis: Die Schalter existieren, aber sie müssen jemandem gehören. Wer Agenten in der Grundeinstellung verteilt und auf das Beste hofft, hat keine Governance. Wie Architektur und Arbeitsweise solcher Plattformen aussehen, bündelt das Themenfeld KI in der Softwareentwicklung.

Qualitätssicherung: Warum KI-Code einen zweiten Blick braucht

Dass eine Anwendung funktioniert, heißt noch nicht, dass sie sicher ist. Das Problem ist alt, wird aber größer, wenn Menschen Code einsetzen, den sie nicht lesen können.

Die Forschung dazu ist uneinheitlich, die Richtung aber deutlich. In einer Studie der Stanford University (Perry und andere, 2022) schrieben Teilnehmende mit KI-Assistent häufiger unsicheren Code und hielten ihn zugleich öfter für sicher. Der Sicherheitsanbieter Veracode ließ 2025 mehr als 100 Sprachmodelle 80 Programmieraufgaben lösen; in 45 Prozent der Fälle enthielt der Code eine Sicherheitslücke. Das ist eine Studie eines Anbieters, der Prüfwerkzeuge verkauft, und sie misst Testaufgaben, keinen Anteil unsicherer Anwendungen im Betrieb. Als Warnsignal taugt sie trotzdem.

Wie das in der Praxis aussieht, zeigte 2025 eine Schwachstelle mit der Kennung CVE-2025-48757. In Apps, die mit dem KI-Baukasten Lovable erzeugt worden waren, waren die Zugriffsregeln für einzelne Datensätze in der Datenbank unzureichend. Nicht angemeldete Angreifer konnten dadurch Tabellen lesen und verändern. Lovable bestreitet die Einstufung als Schwachstelle der Plattform: Für den Schutz der Daten sei jeder Kunde selbst verantwortlich. Die Apps liefen einwandfrei, sie schützten nur nichts.

BSI und ANSSI formulieren es nüchtern: KI-Programmierassistenten sind kein Ersatz für erfahrene Entwickler. Als Gegenmaßnahmen nennen sie, erzeugten Code zu prüfen und zu verstehen, automatische Funktionstests, automatische Schwachstellenscanner und zusätzliche Reviews durch Sicherheitsteams, die mit der wachsenden Menge an KI-Code gegebenenfalls mitwachsen müssen. Für Fachabteilungs-Apps folgt daraus: Automatische Prüfungen laufen bei jeder Änderung mit, und bevor eine App mit echten Daten breit genutzt wird, schaut ein Entwickler auf Anmeldung, Datenzugriff und Geheimnisse wie Passwörter oder API-Schlüssel, die nicht im Code stehen dürfen.

Wer die App betreut, wenn ihr Erbauer geht

Die unbequemste Frage stellt sich meist erst ein Jahr später. Angenommen, die Kollegin, die die Personal-App gebaut hat, wechselt die Stelle. Die Anwendung läuft weiter, bis eine verwendete Programmbibliothek eine Sicherheitslücke hat, das Lohnsystem seine Schnittstelle ändert oder ein neues Feld gebraucht wird. Dann sucht man jemanden, der die App versteht, und findet niemanden.

Ein großer Teil der Kosten einer Software entsteht erst nach der Fertigstellung: Updates, Anpassungen, Fehlerbehebung, Betrieb. Das gilt für kleine Eigenbauten genauso wie für große Systeme. Das Papier von BSI und ANSSI weist zusätzlich darauf hin, dass fehlerhafte oder frei erfundene Erklärungen, Kommentare und Dokumentation eines KI-Assistenten die Wartbarkeit des Codes verringern können, und empfiehlt, dass Programmierer den Betrieb auch ohne KI-Assistenz aufrechterhalten können, etwa bei einem Störfall.

Für jede App, die mehr als eine Person nutzt, braucht es deshalb drei Festlegungen: eine benannte verantwortliche Person in der Fachabteilung, eine Vertretung und einen Prüftermin, an dem entschieden wird, ob die App weiterlebt, in die Obhut der IT wechselt oder abgeschaltet wird. Dazu gehört ein einfaches Verzeichnis aller Eigenbau-Anwendungen. Für die Power Platform zeigt Microsoft im Power Platform Admin Center unter „Inventory“ alle Apps, Flows und Agenten eines Mandanten an; das frühere CoE Starter Kit wird nicht mehr weiterentwickelt. Für Apps aus Coding Agents genügt anfangs eine gepflegte Liste.

Auch die Rechnung „selbst bauen statt kaufen“ sieht dann anders aus. Eine Lizenz enthält Wartung, Sicherheitsupdates und Support. Wer sie durch Eigenbau ersetzt, spart den Preis, übernimmt aber diese Aufgaben. Bei einem Dashboard für einen überschaubaren Nutzerkreis kann sich das rechnen, bei einer Anwendung, an der Abrechnung oder Kundendaten hängen, deutlich seltener. Die 100.000 US-Dollar aus der Fallstudie sind deshalb eine Bruttozahl, keine Ersparnis unter dem Strich.

Was in Deutschland rechtlich dazukommt

Eine selbst gebaute App ist rechtlich kein Privatvergnügen. Verantwortlich ist das Unternehmen, gleich wer sie programmiert hat. Die wichtigsten Punkte im Überblick, als allgemeine Information und nicht als Rechtsberatung:

• DSGVO: Verarbeitet die App personenbezogene Daten, gelten Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen (Art. 25), sie gehört ins Verzeichnis von Verarbeitungstätigkeiten (Art. 30), und bei voraussichtlich hohem Risiko ist eine Datenschutz-Folgenabschätzung nötig (Art. 35). Die Datenschutzkonferenz führt auf ihrer Muss-Liste ausdrücklich die umfangreiche Verarbeitung von Daten über das Verhalten von Beschäftigten auf, die zur Bewertung ihrer Arbeit so eingesetzt werden können, dass sich daraus Rechtsfolgen für sie ergeben oder sie in anderer Weise erheblich beeinträchtigt werden (Nr. 8). Ein Werkzeug für Leistungsbeurteilungen liegt nahe an diesem Fall; ob es „umfangreich“ ist, bleibt eine Frage des Einzelfalls.
• Betriebsrat: Nach § 87 Abs. 1 Nr. 6 BetrVG bestimmt der Betriebsrat bei technischen Einrichtungen mit, die dazu bestimmt sind, Verhalten oder Leistung der Beschäftigten zu überwachen. Die Rechtsprechung legt das objektiv aus: Es genügt, dass die Einrichtung dazu geeignet ist. Das Bundesarbeitsgericht hat im Dezember 2016 (1 ABR 7/15) sogar die Funktion „Besucher-Beiträge“ auf der Facebook-Seite eines Arbeitgebers als mitbestimmungspflichtig eingestuft, weil Besucher dort Beiträge über Verhalten oder Leistung von Beschäftigten veröffentlichen konnten. Eine selbst gebaute HR-App, die Feedback sammelt und zusammenführt, dürfte nach meiner Einschätzung darunterfallen, auch wenn niemand kontrollieren will.
• NIS2: Seit dem 6. Dezember 2025 gilt in Deutschland das Gesetz zur Umsetzung der europäischen NIS2-Richtlinie. Betroffene Unternehmen müssen die Risiken für ihre IT systematisch steuern, die Geschäftsleitung trägt dafür die Verantwortung. Eigenbau-Anwendungen mit Zugriff auf Kernsysteme gehören dann ins Risikomanagement; eine App, von der die IT nichts weiß, ist ein blinder Fleck.
• AI Act: Hier lohnt die genaue Unterscheidung. Dass eine App mit KI programmiert wurde, macht sie nicht zum Hochrisiko-System. Anders sieht es aus, wenn die App selbst KI einsetzt, um etwa Leistung oder Verhalten von Beschäftigten zu bewerten (Anhang III Nr. 4). Die Pflichten für solche Systeme gelten nach der Verschiebung durch den sogenannten Digital-Omnibus ab dem 2. Dezember 2027.

Welche Regeln und Normen im Einzelnen zu beachten sind, behandelt das Themenfeld Compliance und Standards.

Drei Freigabestufen als praktische Leitplanke

Nicht jede App braucht dasselbe Prüfverfahren. Ein Werkzeug, das nur die eigene Arbeit erleichtert, ist etwas anderes als eine Anwendung, mit der die Personalabteilung Beurteilungen verwaltet. Microsoft beschreibt in seinem Leitfaden zur Umgebungsstrategie der Power Platform, wie das Unternehmen die eigenen Umgebungen nach Risiko in drei Kategorien einteilt: persönliche Produktivität, Zusammenarbeit im Team und unternehmensweite Entwicklung. Das Schema lässt sich gut auf Apps übertragen, die mit Coding Agents entstehen. Mein Vorschlag für drei Stufen:

Stufe 1: persönliches Werkzeug

• Beispiel: ein Skript, das die eigenen Reisekostenbelege sortiert, oder eine Auswertung eigener Tabellen.
• Rahmen: freigegebenes Werkzeug mit Unternehmenskonto, keine personenbezogenen Daten Dritter, kein Zugriff auf Produktivsysteme, kein Teilen mit anderen.
• Nötig: Grundschulung, schriftliche Nutzungsregeln und zentral voreingestellte Sicherheitsgrenzen im Werkzeug. Eine Einzelfreigabe entfällt.

Stufe 2: Team-Anwendung

• Beispiel: eine Urlaubs- oder Schichtübersicht für eine Abteilung, ein Dashboard mit Vertriebszahlen.
• Rahmen: Nutzung durch einen begrenzten Personenkreis, Daten nur über freigegebene Schnittstellen, Anmeldung über das Unternehmenskonto.
• Nötig: Eintrag im App-Verzeichnis mit verantwortlicher Person und Vertretung, Code auf der gemeinsamen Plattform, automatische Sicherheitsprüfung, kurze Freigabe durch die IT. Bei personenbezogenen Daten zusätzlich der Eintrag ins Verarbeitungsverzeichnis.

Stufe 3: unternehmensweit oder mit sensiblen Daten

• Beispiel: der Workflow für Leistungsbeurteilungen, eine App mit Kundendaten, alles mit Schreibzugriff auf geschäftskritische Systeme.
• Rahmen: Betrieb nur nach formaler Freigabe und in der Produktionsumgebung der IT.
• Nötig: Review durch Entwicklung und Informationssicherheit, getrennte Test- und Produktionsumgebung, automatisierte Tests, Datenschutzprüfung bis hin zur Folgenabschätzung, bei Beschäftigtendaten die Beteiligung des Betriebsrats, eine verbindliche Zusage für Betrieb und Wartung sowie regelmäßige Nachprüfung. Microsoft sieht für diese Kategorie ebenfalls einen geregelten Lebenszyklus mit Vorproduktion und wiederkehrende Sicherheits- und Datenschutzprüfungen vor.

Entscheidend ist der Übergang zwischen den Stufen. Eine App, die als persönliches Werkzeug begann, wandert oft unbemerkt in Stufe 2 oder 3, weil Kolleginnen und Kollegen den Link weitergeben. Deshalb sollte das Teilen technisch begrenzt sein, und der Schritt in die nächste Stufe sollte ein bewusster Antrag sein, kein Zufall.

Schulung gehört zu den Leitplanken

Die Fallstudie nennt Hackathon und Management-Session nicht ohne Grund. Wer mit einem Coding Agent arbeitet, muss kein Programmierer werden, sollte aber einiges verstehen: wie man eine Anforderung präzise beschreibt, warum Zugangsdaten weder in den Code noch in die Eingabe an die KI gehören, was eine Zugriffsregel in der Datenbank leistet und wann man die IT hinzuzieht. BSI und ANSSI warnen ausdrücklich vor dem „Automation Bias“, dem Hang, den Ergebnissen einer Maschine zu sehr zu vertrauen.

Ebenso wichtig ist die Schulung auf der anderen Seite. Entwicklerinnen und Entwickler, die künftig vor allem prüfen und begleiten, brauchen einen geschulten Blick für typische Fehler in KI-generiertem Code und Verständnis für die Abläufe der Fachabteilungen. Führungskräfte müssen einschätzen können, in welche Stufe eine Idee gehört. Wie Teams diese Arbeitsweise praktisch lernen, zeigt das Seminar Vibe Coding mit KI-Agenten.

Was das für Ihr Unternehmen bedeutet

Die Entwicklung lässt sich nicht aufhalten, und das muss sie auch nicht. Fachabteilungen kennen ihre Abläufe am besten, und viele kleine Werkzeuge, die bisher an fehlenden Kapazitäten scheiterten, werden jetzt machbar. Überschätzt wird allerdings, wie viel davon ohne IT geht. Selbst die Herstellerfallstudie beschreibt als Ausgangspunkt eine vorher vereinheitlichte Entwicklungsplattform, aufbereitete Daten und Schulungen, dazu Sprechstunden der Entwicklung zweimal pro Woche und Ingenieure, die in ausgewählten Bereichen mitarbeiten. Begleitung durch Entwickler gehört also auch nach Darstellung des Herstellers zum Erfolg.

Meine Empfehlung: Beginnen Sie nicht mit dem Werkzeug, sondern mit drei Entscheidungen. Welches Werkzeug stellen wir offiziell bereit? Welche Daten geben wir über welche Schnittstellen frei? Und wer prüft was in welcher Stufe? Wer diese Fragen beantwortet, bevor die ersten Apps ungefragt entstehen, bekommt eine Werkstatt mit Leitplanken statt eines Wildwuchses, den man später mühsam einfangen muss. Die IT baut dann weniger selbst und wird trotzdem wichtiger als zuvor.

Häufige Fragen zu Fachabteilungs-Apps mit KI-Agenten

Brauchen Fachabteilungen dafür Programmierkenntnisse?

Nicht im klassischen Sinn. Sie sollten ihr Problem präzise beschreiben, Ergebnisse gründlich testen und typische Risiken erkennen können. Sobald eine App über das persönliche Werkzeug hinauswächst, gehört die Begleitung durch Entwickler dazu.

Ist eine mit KI gebaute HR-App automatisch ein Hochrisiko-System nach dem AI Act?

Nein. Entscheidend ist, ob die App selbst KI einsetzt, um Beschäftigte zu bewerten. Unabhängig davon können Datenschutzrecht und Mitbestimmung greifen, und zwar schon heute.

Sollte man private KI-Zugänge einfach verbieten?

Ein Verbot allein verlagert die Nutzung meist nur ins Verborgene. Wirksam wird ein Verbot privater Zugänge erst zusammen mit einem freigegebenen Angebot mit Unternehmenskonto, zentralen Einstellungen und klaren Regeln. Diese Kombination empfehlen auch BSI und ANSSI.