Die neue Größenklasse. Und was sie für KI im Haus ändert.

/01Small Mid-Caps: Begriff und Abgrenzung

Die Kategorie Small Mid-Cap — kleines Unternehmen mittlerer Kapitalisierung, kurz SMC — stammt aus der Empfehlung (EU) 2025/1099 der Kommission vom 21. Mai 2025. Ihr Anhang definiert in Nummer 2: Unternehmen, die kein KMU nach der Empfehlung 2003/361/EG sind, weniger als 750 Personen beschäftigen und einen Jahresumsatz von höchstens 150 Millionen Euro oder eine Bilanzsumme von höchstens 129 Millionen Euro haben. Die Kategorie schließt also nach unten an die KMU-Grenze an und endet bei 750 Köpfen — ein Betrieb mit 400 Beschäftigten und 90 Millionen Euro Umsatz ist ein SMC, einer mit 800 Beschäftigten nicht, und einer mit 600 Beschäftigten und 200 Millionen Euro Umsatz auch nicht, es sei denn, seine Bilanzsumme liegt unter 129 Millionen.

Die Empfehlung selbst verpflichtet niemanden; sie ist ein Baukasten für Rechtsakte, die auf sie verweisen. Der EU AI Act tut das seit dem Digital Omnibus: Artikel 3 Nummer 14b verweist für den Begriff auf genau diese Anhangsnummer, und Artikel 1 Absatz 2 Buchstabe g nennt die Förderung von Innovation „mit besonderem Schwerpunkt auf SMC und KMU" jetzt ausdrücklich als Regelungsziel. Was die Kategorie nicht ist: keine Verpflichtung, keine Registrierung, kein Status, den eine Behörde verleiht. Ein Unternehmen ist SMC, wenn es die Schwellen erfüllt — und hört auf, es zu sein, wenn es sie überschreitet.

Wichtig für Konzerntöchter und Beteiligungen: Nummer 3 des Anhangs übernimmt die Logik der KMU-Empfehlung zu Partnerunternehmen und verbundenen Unternehmen. Beschäftigte und Umsatz werden anteilig oder vollständig zusammengerechnet. Ein Betrieb mit 300 Köpfen, der zu einem Konzern mit 5.000 gehört, ist kein SMC.

/02Was die Einstufung im AI Act konkret bringt

Die Verordnung (EU) 2026/1744 hat die Bestimmungen, die bisher nur KMU begünstigten, an mehreren Stellen um SMC erweitert. Im Volltext finden sich folgende Erleichterungen:

Die greifbarste Erleichterung ist die Bußgeldregel. Ein SMC mit 100 Millionen Euro Umsatz, das gegen die Transparenzpflicht verstößt, sieht sich einer Obergrenze von 3 Prozent des Umsatzes gegenüber — 3 Millionen Euro — und nicht dem Festbetrag von 15 Millionen. Vor dem Omnibus galt für dieses Unternehmen der höhere Wert. Die übrigen Erleichterungen betreffen Hochrisiko-Anbieter und werden erst mit dem Geltungsbeginn von Kapitel III praktisch.

/03Was sie nicht bringt

Die Liste der Erleichterungen ist kürzer als der Name der Verordnung vermuten lässt, und drei Dinge fehlen ausdrücklich. Erstens: Die Verbote nach Artikel 5 gelten für ein SMC genauso wie für einen Konzern, und die Bußgeldstufe für verbotene Praktiken — 35 Millionen Euro oder 7 Prozent, je nachdem, was höher ist — ist von der Niedrigerer-Wert-Regel des neuen Absatzes 6a ausgenommen. Nur KMU nach Absatz 6 profitieren dort. Zweitens: Die KI-Kompetenzpflicht nach Artikel 4 und die Transparenzpflichten nach Artikel 50 gelten unverändert; kein Absatz nimmt SMC aus. Drittens: Keine Frist verschiebt sich für SMC anders als für alle anderen — die Hochrisiko- Termine 2. Dezember 2027 und 2. August 2028 gelten für jede Unternehmensgröße.

Was die Einstufung außerdem nicht ist: eine Aussage über die Betriebsform. Nichts im AI Act verlangt oder begünstigt, dass ein SMC sein Sprachmodell im eigenen Haus betreibt. Die Verordnung ist technologie- und standortneutral. Wer On-Premise-KI mit „der AI Act verlangt das" begründet, argumentiert falsch. Die richtigen Gründe sind andere, und sie folgen weiter unten.

/04Anbieter oder Betreiber: die Rolle wiegt mehr als die Größe

Was den Pflichtenumfang bestimmt, ist nicht die Beschäftigtenzahl, sondern die Rolle nach Artikel 3. Betreiber (Nummer 4) ist, wer ein KI-System in eigener Verantwortung verwendet. Anbieter (Nummer 3) ist, wer ein System entwickelt oder entwickeln lässt und es unter eigenem Namen in Verkehr bringt oder — das ist der Punkt — in Betrieb nimmt. Ein Betrieb, der ein Open-Weight-Modell herunterlädt, eine Wissensbasis anschließt und das Ergebnis als „unser Assistent" an seine Beschäftigten oder Kunden ausrollt, entwickelt ein KI-System und nimmt es unter eigenem Namen in Betrieb. Nach dem Wortlaut ist er Anbieter und Betreiber zugleich.

Solange das System kein Hochrisiko-System ist, sind die Folgen überschaubar: Die Anbieterpflicht aus Artikel 50 Absatz 1 — der Hinweis, dass die Person mit einer KI spricht — und Absatz 2 — die maschinenlesbare Kennzeichnung erzeugter Inhalte — treffen den Betrieb direkt, nicht nur mittelbar über einen Hersteller. Wird das System später für eine Anhang-III-Aufgabe verwendet, etwa zur Vorauswahl von Bewerbungen, ist der Betrieb Anbieter eines Hochrisiko-Systems mit allen Pflichten aus Kapitel III — und genau dort greifen dann die SMC-Erleichterungen bei Dokumentation und Qualitätsmanagement.

Wer ein System nur einkauft und nach Herstelleranleitung verwendet, bleibt Betreiber. Artikel 25 zieht die Grenze: Wer ein System wesentlich verändert, unter eigenem Namen anbietet oder seine Zweckbestimmung ändert, wird zum Anbieter; der Omnibus hat Verstöße gegen Artikel 25 ausdrücklich in den Bußgeldkatalog aufgenommen. Die Einzelheiten zu Rollen und Nachweisen stehen in KI-Agenten rechtssicher betreiben; belastbar ist die Einordnung des eigenen Systems nur mit anwaltlicher Prüfung.

/05Die typische Ausgangslage bei 250 bis 750 Beschäftigten

Die SMC-Größe hat ein eigenes Profil, das wir aus Projekten kennen — als Beobachtung, nicht als Statistik. Die IT hat meist drei bis zehn Köpfe, ein ERP mit zwanzig Jahren Geschichte, mehrere Standorte, oft eine Virtualisierungsumgebung oder einen VMware-Bestand im Umbruch, und ein ISMS, weil ein Großkunde oder TISAX es verlangt hat. Es gibt Betriebsgeheimnisse, die den Wert des Unternehmens ausmachen: Konstruktionsdaten, Rezepturen, Kalkulationen, Kundenlisten. Und es gibt seit zwei Jahren Beschäftigte, die diese Daten in private KI-Konten kopieren, weil der Betrieb ihnen nichts anderes gegeben hat.

Das ist die Lage, in der die Frage nach On-Premise-KI gestellt wird — und sie wird meist falsch gestellt: als Technikfrage („Welche GPU?") statt als Betriebsfrage („Wer ist nachts zuständig?"). Ein SMC hat, anders als ein KMU mit dreißig Köpfen, genug Nutzer, um ein eigenes Modell auszulasten, und genug vertrauliche Daten, um den Aufwand zu rechtfertigen. Was ihm oft fehlt, ist die Betriebsorganisation für einen weiteren Dienst mit Bereitschaft, Sicherung und Versionsverwaltung.

/06Eigene Hardware, Rechenzentrum oder API: die Entscheidungslogik

Drei Betriebsformen stehen zur Wahl, und keine ist für die ganze SMC-Klasse richtig. Die Entscheidung fällt je Arbeitslast, nicht je Unternehmen:

• Eigene Hardware im eigenen Haus. Ein oder zwei Inferenzserver mit professionellen Karten, betrieben mit vLLM oder einem vergleichbaren Server. Daten verlassen das Gebäude nicht; das Modell ist unter voller Kontrolle; die Kosten sind fix. Voraussetzung sind ein Serverraum mit Strom und Kühlung, jemand, der die Karten betreibt, und eine Auslastung, die die Anschaffung trägt.
• Dedizierte Hardware im deutschen Rechenzentrum. Dieselbe Kontrolle über Modell und Daten, aber Strom, Kühlung, Zutritt und Hardwaretausch beim Betreiber; Anbindung über eine eigene Leitung oder VPN. Für SMC ohne eigenen Serverraum oder mit mehreren Standorten oft die praktikablere Form.
• API eines Modellanbieters. Kein Betrieb, kein Kapital, das stärkste Modell. Dafür laufen Daten zum Anbieter — mit Auftragsverarbeitungsvertrag, Standortfrage und dem Risiko, dass das Modell ohne Ankündigung wechselt.

Die Rechnung zwischen eigener Karte und API hängt an einer Zahl: der Tokenmenge, die ein Betrieb tatsächlich erzeugt. Unter einem bestimmten Volumen ist die API billiger, darüber die eigene Hardware; wo die Grenze liegt, haben wir in GPU-Preise 2026: Eigene KI-Hardware oder API-Tokens rechnen mit Beispielwerten durchgerechnet. Belastbar ist die Rechnung nur mit den eigenen Nutzungszahlen aus einem Pilotbetrieb von einigen Wochen. Ein SMC mit dreihundert Nutzern eines internen Assistenten liegt erfahrungsgemäß über der Grenze; ein SMC mit einem einzigen Bot für Bestellstatus darunter.

/07Datenklassen und Standort: was im Haus bleiben muss

Der tragfähige Grund für KI im eigenen Haus ist nicht der AI Act, sondern die Datenklasse. Eine Klassifikation in drei oder vier Stufen — öffentlich, intern, vertraulich, streng vertraulich — hat ein SMC mit ISMS ohnehin. Sie entscheidet, welche Betriebsform für welche Arbeitslast zulässig ist:

Die DSGVO kommt hinzu, sobald personenbezogene Daten im Spiel sind — bei Kundendaten, Bewerbungen und Beschäftigtendaten immer. Ein Assistent im eigenen Haus braucht dafür keinen AVV mit einem Modellanbieter, aber eine Rechtsgrundlage, ein Verarbeitungsverzeichnis und, je nach Datenklasse, eine Folgenabschätzung. On-Premise vereinfacht den Datenschutz; es ersetzt ihn nicht. Was dabei zu beachten ist, steht in KI On-Premise: DSGVO-konforme KI-Lösungen.

/08Governance in dieser Größe: Inventar, Rollen, Nachweise

Ein SMC hat genug KI-Systeme, dass niemand sie mehr im Kopf hat, und zu wenig Verwaltung, um eine eigene Compliance-Abteilung dafür abzustellen. Der Ausweg ist, die Governance an die Strukturen zu hängen, die es schon gibt. Drei Bausteine reichen für den Anfang:

• Inventar. Jedes KI-System mit Zweck, Rolle (Anbieter oder Betreiber), Modell und Version, Betriebsform, Datenklassen, Verantwortlichem. Auch die Funktionen in Bürosoftware, Telefonanlage und ERP. Das Inventar ist zugleich die Werkzeugliste für Artikel 4 und die Grundlage für jede spätere Hochrisiko-Prüfung.
• Rollen. Ein Verantwortlicher je System, eine Stelle für Freigaben neuer Systeme, ein Meldeweg für Fehler und Vorfälle. Im ISMS ist das ein Asset-Typ mit Eigentümer; wer ISO 42001 anstrebt, hat damit den Kern des Managementsystems.
• Nachweise. Richtlinie, Einweisungen, Kennzeichnung nach Artikel 50, Protokolle des Betriebs. Bei Anhang-III-Systemen ab 2027 zusätzlich die Betreiberpflichten aus Artikel 26: Aufsicht durch benannte Personen, Protokollaufbewahrung, Monitoring nach Herstelleranleitung.

Wer als Anbieter eines selbst gebauten Systems auftritt, kommt um technische Dokumentation und ein Qualitätsmanagement nicht herum, sobald das System Hochrisiko ist — und hier zahlt sich die SMC-Einstufung aus: Das vereinfachte Formular nach Artikel 11 und die Verhältnismäßigkeit nach Artikel 17 Absatz 2 sind genau für Betriebe dieser Größe geschrieben. Bis das Formular der Kommission vorliegt, ist Anhang IV in voller Länge der Maßstab.

/09Wo es hakt: Grenzen und Fallstricke

Die Grenze zählt den Verbund. Wer zu einem Konzern gehört oder an dem ein anderes Unternehmen 25 Prozent oder mehr des Kapitals oder der Stimmrechte hält, rechnet nach Nummer 3 des Anhangs anteilig oder vollständig zusammen. Viele Betriebe, die sich als SMC sehen, sind es nach dieser Rechnung nicht — und umgekehrt.

Der Status wandert. Ein Betrieb mit 720 Beschäftigten, der wächst, verliert die Einstufung; einer, der schrumpft, gewinnt sie. Nach Nummer 4.2 des Anhangs tritt beides erst ein, wenn die Schwellen in zwei aufeinanderfolgenden Geschäftsjahren über- oder unterschritten werden. Wer Erleichterungen in Anspruch nimmt, sollte den Status jährlich prüfen und den Nachweis ablegen.

Das vereinfachte Formular gibt es noch nicht. Artikel 11 verpflichtet die Kommission, es zu erstellen. Bis dahin ist die Erleichterung ein Versprechen; wer heute ein Hochrisiko-System für 2027 vorbereitet, sollte mit dem vollen Anhang IV planen und später kürzen.

Der Anbieterstatus schleicht sich ein. Ein RAG-Assistent, der als Pilot für die IT gebaut wurde, wird von der Personalabteilung entdeckt und für die Sichtung von Bewerbungen genutzt. Damit ist er ein Anhang-III-System, der Betrieb Anbieter und Betreiber, und die Frist ist der 2. Dezember 2027. Ohne Inventar und Freigabestelle merkt das niemand.

Hardware bindet Personal. Zwei Inferenzserver im Keller brauchen jemanden, der Treiber, Modellversionen und Sicherung pflegt, und jemanden, der einspringt, wenn der Erste im Urlaub ist. In einer IT mit drei Köpfen ist das der Grund, warum das Rechenzentrum oder ein Betriebsvertrag die bessere Form ist — nicht die Technik.

/10Die Entscheidung: wann On-Premise lohnt — und wann nicht

On-Premise lohnt sich, wenn drei Bedingungen zusammenkommen: Die Arbeitslast betrifft vertrauliche oder streng vertrauliche Daten, die Nutzungsmenge liegt über der Grenze, an der die API teurer wird, und es gibt einen Betrieb mit Vertretung — im Haus oder vertraglich. Ein SMC mit Konstruktionsdaten, dreihundert Nutzern eines internen Assistenten und einem ISMS erfüllt alle drei in der Regel.

Das deutsche Rechenzentrum ist die richtige Form, wenn die ersten beiden Bedingungen zutreffen, aber kein Serverraum und keine Bereitschaft vorhanden sind — der häufigste Fall in dieser Größe. Kontrolle über Modell und Daten bleibt; der Hardwarebetrieb liegt beim Betreiber.

Die API ist richtig für öffentliche und interne Datenklassen mit geringem Volumen und für Aufgaben, die das stärkste verfügbare Modell brauchen — mit AVV, EU-Standort und einem Ausstiegsplan, falls der Anbieter das Modell wechselt.

Nichts davon lohnt sich, solange es kein Inventar, keine Datenklassifikation und keinen Verantwortlichen gibt. Dann ist die erste Investition nicht die GPU, sondern ein Tag mit der Geschäftsführung, an dem diese drei Dinge entstehen.

/11Häufige Fragen