IT-Dienstleister müssen den EU AI Act nicht erst dann beachten, wenn sie ein eigenes Foundation Model trainieren. Sobald ein Systemhaus ein KI-System unter eigener Marke anbietet oder ein bestehendes System wesentlich ändert, greifen Anbieterpflichten nach Art. 16 und Art. 25 der EU-VO 2024/1689; Art. 4 zur KI-Kompetenz gilt bereits seit dem 2. Februar 2025.
Für IT-Dienstleister ist die Rollenklärung deshalb wichtiger als das Buzzword auf dem Angebot. Wer nur ein fremdes Tool intern nutzt, ist regelmäßig Betreiber im Sinne von Art. 3 Nr. 4. Wer dagegen eine KI-Lösung entwickelt, entwickeln lässt oder unter eigener Marke beim Kunden in Betrieb nimmt, kann Anbieter nach Art. 3 Nr. 3 sein. Genau diese Unterscheidung entscheidet darüber, ob Sie vor allem Schulung, Governance und saubere Einsatzprozesse brauchen oder zusätzlich in Konformitätsbewertung, technische Dokumentation und Post-Market-Monitoring hineinlaufen.
Wann ist ein IT-Dienstleister Anbieter statt Betreiber?
IT-Dienstleister sind Anbieter, wenn sie ein KI-System unter eigenem Namen oder eigener Marke in Verkehr bringen oder in Betrieb nehmen. Das betrifft klassische SaaS-Anbieter mit KI-Funktion ebenso wie Systemhäuser, die eine Eigenlösung verkaufen, ein White-Label-Produkt unter eigener Marke vertreiben oder ein Kundenprodukt so tief umbauen, dass daraus funktional ein neues System entsteht.
Betreiber bleiben Sie, wenn Sie KI nur für Ihre eigene Organisation einsetzen oder beim Kunden eine Drittanbieter-Lösung ohne wesentliche Änderung ausrollen. Ein Copilot-Rollout, eine Standardintegration von Azure AI Services oder die Einführung von ChatGPT Enterprise macht ein Systemhaus nicht automatisch zum Anbieter. Kritisch wird es, wenn Sie Zweck, Logik, Risikoprofil oder Compliance-relevante Eigenschaften so verändern, dass die Verantwortung nicht mehr sinnvoll beim ursprünglichen Hersteller verbleibt.
Typische KI-Systeme von IT-Dienstleistern und ihre Risikoklassen
Die Risikoklasse hängt bei IT-Dienstleistern nicht an der Technologie, sondern am konkreten Einsatzkontext. Für die Praxis hilft diese Einordnung:
| System oder Leistung | Typische Rolle des IT-Dienstleisters | Risikoklasse nach EU AI Act | | --- | --- | --- | | Interner Coding- oder QA-Assistent für das eigene Team | Betreiber | Meist minimales Risiko, aber Art. 4 gilt trotzdem | | Kunden-Helpdesk-Chatbot unter eigener Marke | Anbieter oder nachgelagerter Anbieter | Meist begrenztes Risiko mit Transparenzpflichten nach Art. 50 | | Bewerber-Scoring, CV-Screening oder Matching-SaaS für Kunden | Anbieter | Hochrisiko nach Anhang III Nr. 4 | | Kreditwürdigkeits- oder Versicherungs-Risikomodell für Kunden | Anbieter | Hochrisiko nach Anhang III Nr. 5 | | Eigenes GPAI-Modell oder stark generalisierbares Basismodell | GPAI-Anbieter | Keine eigene Risikoklasse wie bei Anhang III, aber Pflichten nach Art. 53 seit dem 2. August 2025 |
Die wichtigste Konsequenz für Systemhäuser lautet deshalb: Nicht jede KI ist Hochrisiko, aber viele kundennahe Branchenlösungen sind es. Wer Recruiting-, Finanz-, Bildungs-, Biometrie- oder kritische Infrastruktur-Anwendungen entwickelt, landet schnell im High-Risk-Regime ab dem 2. August 2026 nach Art. 113.
Welche Anbieterpflichten treffen Systemhäuser konkret?
Anbieterpflichten sind für IT-Dienstleister vor allem dann relevant, wenn sie Hochrisiko-KI bereitstellen. Dann greift nicht nur Art. 16, sondern das gesamte Anforderungspaket aus Art. 8 bis 15: Risikomanagement, Daten-Governance, technische Dokumentation, Logging, Information für Betreiber, menschliche Aufsicht sowie Anforderungen an Genauigkeit, Robustheit und Cybersicherheit.
Für die Praxis bedeutet das meist fünf Arbeitspakete:
- Produkt und Zweck sauber definieren. Ohne klaren intended purpose können Sie die Risikoklasse und die Konformitätslogik nicht belastbar festlegen.
- Technische Dokumentation früh aufbauen. Für Hochrisiko-KI reicht ein Architekturdiagramm nicht; relevant sind auch Datenquellen, Tests, Grenzen, Aufsicht und Monitoring.
- Konformitätsbewertung vor Go-live vorbereiten. Bei High-Risk-Systemen muss die Konformität vor Inverkehrbringen oder Inbetriebnahme stehen, nicht erst nach dem ersten Kundenprojekt.
- Kundeninformationen und Nutzungsgrenzen liefern. Betreiber müssen wissen, wofür das System gedacht ist, welche Eingaben zulässig sind und wo menschliche Kontrolle notwendig bleibt.
- Post-Market-Monitoring organisieren. Anbieter müssen Fehler, Vorfälle und Rückmeldungen systematisch auswerten, statt nur Tickets abzuarbeiten.
Wenn Ihr Unternehmen statt eines KI-Systems ein eigenes GPAI-Modell anbietet, verschiebt sich der Fokus. Dann gelten seit dem 2. August 2025 insbesondere Dokumentations-, Informations- und Urheberrechts-Pflichten aus Art. 53; bei systemischem Risiko kommen zusätzliche Anforderungen aus Art. 55 hinzu.
Wann macht eine wesentliche Änderung Sie selbst zum Anbieter?
Eine wesentliche Änderung kann ein IT-Dienstleister in die Anbieterrolle schieben, obwohl die Ausgangsbasis von einem Dritten stammt. Art. 25 ist genau für diese Konstellation relevant: Wer ein bestehendes KI-System so verändert, dass Compliance-relevante Eigenschaften oder der vorgesehene Zweck neu gesetzt werden, übernimmt Verantwortung nicht mehr nur als Integrator, sondern als Anbieter.
In der Projektpraxis ist nicht jede Konfiguration eine wesentliche Änderung. Unkritischer sind Standardparameter, Rollenrechte oder UI-Anpassungen. Kritisch wird es eher bei eigener Ranking-Logik für Bewerber, zusätzlichem Fine-Tuning für Kreditentscheidungen, neuen Entscheidungsregeln in Safety-Kontexten oder beim Umwidmen eines allgemeinen Modells für einen High-Risk-Zweck. Genau an dieser Stelle sollten Vertrieb, Delivery und Technik dieselbe Sprache sprechen, bevor das Angebot unterschrieben wird.
Was gilt bei Copilot-, Azure-AI- oder ChatGPT-Projekten beim Kunden?
Bei Standard-Rollouts fremder KI-Dienste bleibt der Kunde meist der eigentliche Betreiber, während der Hersteller oder Modellanbieter die Hauptverantwortung für das Produkt trägt. Für IT-Dienstleister entfällt damit aber nicht jede Pflicht. Sie müssen intern trotzdem Art. 4 umsetzen, Projekte sauber klassifizieren und vertraglich klären, wer welche AI-Act-Aufgaben übernimmt.
Praktisch heißt das: Systemhäuser sollten in Leistungsbeschreibung, Architektur und Abnahme festhalten, ob sie nur implementieren, ob sie unter eigener Marke auftreten, ob eine wesentliche Änderung vorliegt und welche Nutzungsgrenzen der Kunde einhalten muss. Wer internationale Tools vertreibt, sollte zusätzlich die Rollen als Importeur oder Händler mitdenken, statt pauschal von “nur Beratung” auszugehen.
Welche Sofortmaßnahmen sind für IT-Dienstleister sinnvoll?
IT-Dienstleister sollten jetzt eine kleine, aber belastbare AI-Act-Basis aufbauen. Drei Schritte haben Priorität:
- Projektportfolio inventarisieren: Welche Lösungen sind reine Nutzung, welche Eigenprodukte, welche White-Label-Angebote und welche potenziellen High-Risk-Use-Cases?
- Rollen pro Projekt festhalten: Anbieter, Betreiber, Händler, Importeur oder nur Implementierungspartner sollte nicht erst im Streitfall geklärt werden.
- Art.-4-Schulung dokumentieren: Entwickler, Consultants, Support, Presales und Führungskräfte sollten ein gemeinsames Mindestverständnis zu Risikoklassen, roten Linien und Kundenkommunikation nachweisen können.
- Vertragsmuster ergänzen: Nutzungsgrenzen, Verantwortlichkeiten, Dokumentationspflichten und Eskalationswege gehören in Kundenverträge und Leistungsbeschreibungen.
- Interne Orientierungspunkte verlinken: Nutzen Sie den Kurs, die FAQ und das Compliance-Quiz, damit Teams nicht mit verstreuten Einzelinformationen arbeiten.
Häufige Fragen aus Systemhäusern
Müssen reine Standardintegrationen schon die vollen Anbieterpflichten erfüllen?
Nein. Wer nur eine Drittanbieter-Lösung ohne wesentliche Änderung implementiert, ist nicht automatisch Anbieter. Die Anbieterpflichten steigen vor allem dort an, wo Sie unter eigener Marke bereitstellen oder das System so verändern, dass Art. 25 eingreift.
Reicht eine Art.-4-Schulung allein für IT-Dienstleister aus?
Nein. Die Schulungspflicht aus Art. 4 gilt zwar schon heute und ist die richtige Sofortmaßnahme. Sobald Ihr Unternehmen aber eigene Hochrisiko-KI anbietet oder eine wesentliche Änderung vornimmt, brauchen Sie zusätzlich Produkt- und Compliance-Prozesse nach Art. 16 ff.
Warum ist diese Branchen-Seite schon vor August 2026 relevant?
Weil IT-Dienstleister ihre Rollen vor Vertragsabschluss klären müssen, nicht erst zum Enforcement-Stichtag. Außerdem gelten Art. 4 seit dem 2. Februar 2025 und die GPAI-Pflichten aus Art. 53 seit dem 2. August 2025 bereits heute.