Wann General-Purpose AI Modelle gelten und was als Naechstes zu tun ist

General-Purpose AI Modelle werden fuer ein SaaS-Team relevant, wenn das Unternehmen ein Modell bereitstellt, integriert, deployed, fine-tuned, konfiguriert oder wesentlich davon abhaengt. Die erste Frage lautet nicht, ob das Unternehmen ein Modelllabor ist. Sie lautet, wo Modelle in Produkt, Vendor Stack, internen Workflows, Kundenzusagen und Nachweisen sitzen.

Nach dem EU AI Act liegen die Kernpflichten in Kapitel V. Artikel 53 verlangt technische Dokumentation, Informationen fuer Downstream Provider, eine Copyright Policy und eine oeffentliche Zusammenfassung von Trainingsinhalten. Artikel 55 fuegt fuer Modelle mit systemischem Risiko Pflichten zu Evaluation, Risikominderung, Incident Reporting und Cybersecurity hinzu. Artikel 51 beschreibt die Einstufung als Modell mit systemischem Risiko.

Wann das praktisch gilt

Es gilt, wenn ein Produkt oder Prozess von einem General-Purpose Modell abhaengt: API-Integration, Copilot, Dokumentenzusammenfassung, Empfehlungen, Klassifizierung, Support-Antworten, Suche, Code- oder Texterzeugung oder kundenseitig konfigurierbare AI Workflows.

Es gilt auch intern. Ein Support-Team mit AI Drafting, ein Sales-Team mit Account Scoring, ein Security-Team mit Alert Triage oder ein Operations-Team mit Kundenzusammenfassungen kann Fragen zu Datenschutz, Security, Copyright, Kundenvertrauen und Rollenmapping ausloesen.

Wann es nicht der Hauptpunkt ist

Bei rein interner, niedrig riskanter Produktivitaetsnutzung kann die wichtigste Frage akzeptable Nutzung, Vertraulichkeit und Security sein, nicht eine volle Modellanbieteranalyse. Trotzdem sollte ein "nicht anwendbar" dokumentiert werden. Ein kleiner Pilot kann zur Produktabhaengigkeit werden, und ein internes Tool kann Kundendaten oder vertrauliche Informationen beruehren.

Schritt 1: Modellinventar

Erstellen Sie ein kurzes Inventar aller Modelle: hosted APIs, Open-Source-Modelle, fine-tuned Modelle, Vendor Features, interne Tools, Produkt-Copilots, Support Assistants, Analytics und kundenseitig konfigurierbare Workflows.

Erfassen Sie Modellname, Anbieter, Version, Hosting, Use Case, Product Owner, technische Owner, Datenkategorien, Kundensichtbarkeit, relevante Outputs, Fine-Tuning, Kundeneinstellungen und Vendor Dokumentation.

Schritt 2: Rolle mappen

Klaeren Sie, ob das Unternehmen Modellanbieter, Downstream Provider eines AI Systems, Deployer, Nutzer eines Vendor Features oder Modifizierer eines Modells ist. Die Rolle bestimmt die Pflichten und die erwartete Evidence.

Diese Rollenmap gehoert in Product Intake, Vendor Review, Security Review, Privacy Review, Architecture Review, Launch Readiness und Customer Trust Dokumentation.

Schritt 3: Provider Evidence sammeln

Wenn ein Drittmodell beteiligt ist, sammeln Sie Provider Evidence frueh. Fragen Sie nach Faehigkeiten, Grenzen, erlaubter Nutzung, Versionierung, Update Notices, Safety- und Evaluation-Informationen, Security Controls, Data Retention, Training von Kundendaten, Copyright Policy, Trainingszusammenfassung und Incident Kommunikation.

Wenn der Anbieter systemisches Risiko nennt, fragen Sie, welche Artikel-55-Nachweise fuer Kunden verfuegbar sind und welche Aenderungen eine Mitteilung ausloesen.

Schritt 4: Review-Pfad entscheiden

Nicht jede Nutzung braucht dieselbe Pruefung. Niedrigschwellige Review passt fuer genehmigte interne Produktivitaet. Standard Review passt fuer Vendor AI Features, Product Copilots, Support Drafting, Analytics und kundensichtbare Outputs. Enhanced Review passt fuer sensible Daten, regulierte Kunden, Fine-Tuning, kritische Produktabhaengigkeiten oder kundenseitig konfigurierbares Verhalten.

Jede Review sollte mit approved, approved with conditions, blocked oder more facts needed enden. Bedingungen brauchen Owner und Termine.

Schritt 5: Change Trigger definieren

Modellentscheidungen altern schnell. Neue Modellversion, neuer Provider, neues AI Feature, neue Datenkategorie, regulierter Kundensektor, Fine-Tuning, Hosting-Aenderung, Vendor Policy Change, Incident oder deutlich anderes Modellverhalten sollten Review erneut ausloesen.

FAQ

Wozu dient Governance fuer General-Purpose AI Modelle praktisch?

Sie zeigt, wo Modelle das Unternehmen betreffen, welche Rolle das Unternehmen hat, welche Nachweise existieren, welche Kontrollen gelten und wann eine erneute Review noetig ist.

Wann gilt das fuer SaaS-Teams?

Wenn ein Team ein General-Purpose AI Modell bereitstellt, integriert, deployed, konfiguriert, fine-tuned oder in Produkt, internem Workflow, Vendor Beziehung oder Enterprise Review nutzt.

Was zuerst dokumentieren?

Starten Sie mit Modellinventar und Rollenmap. Danach folgen Provider Evidence, Modellversion, Use Case, Datenkategorien, Kundensichtbarkeit, Security, Privacy, Copyright, Grenzen, Monitoring, Change Trigger und genehmigte Kundenantworten.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission AI Act Service Desk, Article 51, Article 53, Article 55, Article 56 and Article 113.