25.9.2026

HR-Software und KI: Die neue Make-or-Buy-Frage

Das Wichtigste in Kürze

Mit dem zunehmenden Einsatz von künstlicher Intelligenz kommt bei der HR-Softwareauswahl eine neue Frage hinzu: Soll die KI Bestandteil der HR-Software sein, oder soll die HR-Lösung an eine bereits im Unternehmen vorhandene KI angebunden werden? Diese Make-or-Buy-Frage für KI-Architektur wird bei künftigen Auswahlprojekten deutlich an Bedeutung gewinnen – unabhängig davon, welche Antwort ein Unternehmen wählt, sollte die Frage explizit Teil des Auswahlprozesses sein.

Was zunächst nach einer technischen Detailfrage klingt, berührt in Wirklichkeit die gesamte zukünftige Systemarchitektur eines Unternehmens. Und es erinnert an eine Diskussion, die IT-Verantwortliche seit Jahrzehnten führen: Make or Buy? Neu ist allerdings, dass es diesmal häufig nicht darum geht, Software selbst zu entwickeln. Vielmehr geht es darum, wo die Intelligenz einer Anwendung künftig angesiedelt ist.

Zwei grundsätzlich unterschiedliche Ansätze

Viele HR-Softwareanbieter integrieren inzwischen eigene KI-Funktionen in ihre Produkte. Daneben entsteht ein zweiter Ansatz: Unternehmen etablieren eine zentrale KI-Umgebung, etwa auf Basis eines unternehmensweiten Assistenten, und verbinden diese mit den eingesetzten Fachanwendungen. Das HR-System liefert dann Daten und Funktionen, während die eigentliche Kommunikation mit dem Nutzer außerhalb der HR-Anwendung stattfindet.

Variante 1: Die KI steckt in der HR-Software

Vorteil: Enge Verzahnung mit Datenmodell und Prozessen, keine eigene KI-Integration durch das Unternehmen nötig.

Risiko: Eine neue Form der Anbieterabhängigkeit – diesmal zusätzlich bei Modellwahl, Datenverarbeitung und KI-Architektur.

Der Anbieter kennt sein eigenes Datenmodell und seine Prozesse, wodurch sich die KI vergleichsweise eng mit der Anwendung verbinden lässt. Berechtigungen, Workflows und Nutzerführung lassen sich aufeinander abstimmen. Für Unternehmen bedeutet dies zudem, dass sie sich nicht selbst um die technische Integration verschiedener KI-Dienste kümmern müssen – gerade für mittelständische Unternehmen ohne eigene KI-Infrastruktur kann das attraktiv sein.

Für die Softwareauswahl werden dadurch neue Fragen relevant: Welches Sprachmodell verwendet der Anbieter, und kann dieses später gewechselt werden? Wo werden Daten verarbeitet, und werden Eingaben oder Ergebnisse gespeichert? Können Unternehmensdaten für das Training verwendet werden? Eine Aussage wie „Unsere Software verfügt über künstliche Intelligenz“ reicht als Bewertungskriterium damit nicht mehr aus.

Variante 2: Die Unternehmens-KI wird zur zentralen Oberfläche

Vorteil: Ein einheitlicher Zugang zu allen Fachsystemen, die KI-Wahl bleibt beim Unternehmen.

Anforderung: Das HR-System muss sich sauber öffnen lassen – über APIs und zunehmend auch über KI-spezifische Standards.

Statt in jedem einzelnen System einen separaten KI-Assistenten zu verwenden, wird eine unternehmensweite KI-Plattform aufgebaut, die auf unterschiedliche Fachanwendungen zugreift – HR wäre dann nur ein Anwendungsbereich von mehreren. Aus Sicht der Nutzer hat das einen erheblichen Vorteil: Sie müssen nicht mehr wissen, in welchem System eine Information gespeichert oder welcher Prozess dort hinterlegt ist.

Für HR-Softwareanbieter bedeutet diese Entwicklung allerdings, dass eine gute Benutzeroberfläche allein möglicherweise nicht mehr ausreicht. Mindestens ebenso wichtig wird die Frage, wie gut sich das System von außen ansprechen lässt. Klassische REST-Schnittstellen bleiben dabei relevant, neue Standards wie das Model Context Protocol (MCP) ergänzen diese Möglichkeiten um eine stärker auf KI-Systeme ausgerichtete Zugriffsschicht.

KriteriumVariante 1: KI im HR-SystemVariante 2: Zentrale Unternehmens-KI
AnbieterabhängigkeitZusätzlich zur Software auch von der KI-Architektur des AnbietersGeringer – die KI-Wahl bleibt beim Unternehmen
IntegrationsaufwandGering, da vom Anbieter bereitgestelltHöher – eigene KI-Plattform und Anbindung nötig
NutzererlebnisInnerhalb der HR-AnwendungSystemübergreifend, eine zentrale Oberfläche für alle Systeme
Passt eher fürMittelstand ohne eigene KI-InfrastrukturGrößere Unternehmen mit unternehmensweiter KI-Plattform

MCP ersetzt keine Schnittstellenstrategie

Bei aller derzeitigen Aufmerksamkeit sollte das Model Context Protocol nicht mit einer universellen Integrationslösung verwechselt werden. Vereinfacht gesagt beschreibt MCP, wie eine KI verfügbare Werkzeuge und Datenquellen erkennen und nutzen kann – etwa den Resturlaub eines Mitarbeiters abrufen, Abwesenheiten eines Teams anzeigen oder einen Urlaubsantrag vorbereiten. Die dahinterliegenden Prozesse bleiben jedoch Aufgabe der HR-Anwendung. MCP ersetzt deshalb weder das Datenmodell noch die Prozesslogik noch klassische Schnittstellen – es entsteht lediglich eine zusätzliche Zugriffsmöglichkeit auf vorhandene Funktionen.

Ein Sprachmodell sollte nicht direkt auf eine HR-Datenbank zugreifen und dort beliebige Änderungen vornehmen können. Zwischen KI und Datenbank müssen weiterhin Berechtigungen, Geschäftslogik und definierte Prozesse stehen – gerade bei personenbezogenen Daten ist diese Trennung entscheidend.

KI → Datenbank
KI → definierte Funktion → Berechtigungsprüfung → HR-Prozess → Datenbank

Die neue Make-or-Buy-Frage

Früher lautete die Frage: Entwickeln wir eine Anwendung selbst, oder kaufen wir Standardsoftware? Heute könnte sie lauten: Nutzen wir die Intelligenz des Softwareanbieters, oder bringen wir unsere eigene KI mit? In vielen Fällen wird die Antwort allerdings nicht „entweder oder“ heißen. Wahrscheinlicher ist ein hybrides Modell: Eine HR-Lösung verfügt über eigene KI-Funktionen, stellt gleichzeitig aber APIs und möglicherweise einen MCP-Zugang bereit. Kunden können dann entscheiden, ob Mitarbeiter direkt mit der KI innerhalb des HR-Systems arbeiten oder ob bestimmte Funktionen über eine zentrale Unternehmens-KI genutzt werden. Diese Offenheit dürfte gerade für größere Organisationen langfristig zu einem wichtigen Auswahlkriterium werden.

Was Unternehmen bei der Softwareauswahl künftig prüfen sollten

Die klassischen Anforderungen an eine HR-Software verschwinden dadurch nicht – Payroll, Zeitwirtschaft, Personaladministration, Recruiting oder Talent Management lassen sich nicht durch einen Chatbot ersetzen. Zusätzlich sollten Unternehmen jedoch die KI-Architektur genauer betrachten.

1. Wie tief ist die KI tatsächlich integriert? Zwischen einer Textgenerierung und einer KI, die HR-Prozesse versteht und ausführen kann, besteht ein erheblicher Unterschied. Unternehmen sollten deshalb konkrete Anwendungsfälle demonstrieren lassen und nicht nur allgemeine KI-Funktionen bewerten – der Reifegrad lässt sich dabei gut anhand des 3-Stufen-Modells der KI-Entwicklung in HR einordnen.

2. Ist das verwendete Modell austauschbar? KI-Modelle entwickeln sich derzeit schnell weiter. Eine langfristige Softwareentscheidung sollte deshalb möglichst wenig von einem einzelnen Modellanbieter abhängig sein.

3. Kann eine eigene Unternehmens-KI angebunden werden? Wenn bereits ein unternehmensweiter KI-Assistent existiert, sollte geprüft werden, ob und wie dieser auf HR-Funktionen zugreifen kann – über MCP, aber auch über saubere APIs und dokumentierte Integrationsmöglichkeiten.

4. Welche Aktionen darf die KI ausführen? Lesen ist etwas anderes als Schreiben. Eine KI, die Resturlaub abfragt, stellt ein überschaubares Risiko dar – anders sieht es aus, wenn sie Stammdaten ändert oder Entscheidungen über Bewerber beeinflusst. Es sollte klar definiert sein, welche Aktionen automatisch ausgeführt werden dürfen und wo eine Bestätigung erforderlich ist.

5. Wie werden Berechtigungen berücksichtigt? Eine Führungskraft, die in der HR-Anwendung bestimmte Informationen nicht sehen darf, darf diese auch nicht über einen KI-Assistenten erhalten. Idealerweise verwendet die KI keine eigene Berechtigungslogik, sondern die vorhandenen Rollen und Rechte des HR-Systems.

6. Wie nachvollziehbar sind Aktionen? Es sollte protokolliert sein, wer eine Aktion ausgelöst hat, welche Funktion ausgeführt wurde und welche Daten verändert wurden – insbesondere bei automatisierten Vorgängen darf die KI nicht zur Blackbox werden.

7. Welche regulatorischen Anforderungen gelten? Der europäische AI Act ordnet bestimmte KI-Systeme im Bereich Beschäftigung und Personalmanagement als Hochrisikosysteme ein. Ein Assistent, der Resturlaub anzeigt, ist etwas grundsätzlich anderes als ein System, das Bewerber bewertet.

Nicht die KI sollte im Mittelpunkt der Auswahl stehen

So wichtig diese neuen Fragen sind: Eine HR-Software sollte nicht ausgewählt werden, weil sie besonders viele KI-Funktionen besitzt. Entscheidend bleibt, ob sie die Anforderungen des Unternehmens erfüllt. Eine schlechte Prozessarchitektur wird durch ein Sprachmodell nicht besser, fehlende Schnittstellen werden nicht automatisch durch einen Chatbot gelöst, und uneinheitliche Stammdaten bleiben auch dann uneinheitlich, wenn sie über eine moderne, sprachgesteuerte Oberfläche abgefragt werden.

Fazit: Die Architektur entscheidet mit

Langfristig könnte diese Entwicklung die Bewertung von HR-Systemen deutlich verändern. Bisher wurde häufig darüber diskutiert, welches System die beste Benutzeroberfläche bietet. Künftig könnte die entscheidendere Frage lauten: Wie gut stellt das System seine Daten, Prozesse und Funktionen für Menschen und für KI-Systeme zur Verfügung? Für Unternehmen, die heute eine neue HR-Software auswählen, ist das noch nicht in jedem Projekt ein entscheidendes Kriterium – bei einer üblichen Nutzungsdauer von HR-Systemen von vielen Jahren sollte die Frage aber zumindest Bestandteil der Auswahl sein.

Wie sollte Ihre HR-IT-Architektur auf KI vorbereitet sein?

Unverbindliches Beratungsgespräch vereinbaren →
Dominic Daubenberger
Senior Consultant

Dominic Daubenberger ist Senior Consultant und Geschäftsführer bei Consult-HR. Durch seine langjährige Tätigkeit als IT Berater mit Schwerpunkt HR Software bringt er reichlich Expertise bei Softwareauswahlprojekten mit. Als Autor mehrerer Fachartikel und Studien zum Thema HR Software ist er zudem ein profunder Kenner des Marktes.

Simple black upward-pointing arrow icon on transparent background.