General-Purpose AI Modelle operationalisieren, ohne Produktentwicklung zu verlangsamen

General-Purpose AI Modelle lassen sich operationalisieren, wenn Teams sie wie einen Produkt- und Vendor-Workflow behandeln, nicht wie ein isoliertes Legal Memo. Der praktische Ablauf ist: Modellinventar fuehren, die Rolle des Unternehmens je Modell klaeren, Modell- und Vendor-Aenderungen leichtgewichtig pruefen, Anbieterunterlagen zentral halten und Nachweise dort erfassen, wo Produktarbeit ohnehin passiert.

Nach dem EU AI Act liegen die Kernpflichten in Kapitel V. Artikel 53 verlangt fuer Anbieter von General-Purpose AI Modellen unter anderem technische Dokumentation, Informationen fuer Downstream Provider, eine Copyright Policy und eine oeffentliche Zusammenfassung der Trainingsinhalte. Artikel 55 ergaenzt fuer Modelle mit systemischem Risiko Pflichten zu Evaluation, Risikominderung, schwerwiegenden Vorfaellen und Cybersecurity. Artikel 51 beschreibt die Einstufung systemischer Risiken, einschliesslich der Vermutung bei mehr als 10^25 Floating Point Operations im Training.

Die meisten SaaS-Unternehmen trainieren keine Frontier-Modelle. Trotzdem koennen sie Modelle integrieren, fine-tunen, in Kundenfunktionen einbauen, von einem Anbieter abhaengen oder Buyer-Fragen zu AI Governance beantworten muessen.

Mit einem Modellinventar beginnen

Listen Sie hosted APIs, Open-Source-Modelle, fine-tuned Modelle, eingebettete Vendor Features, interne AI Tools, Produkt-Copilots, Support-Automatisierung und kundenseitig konfigurierbare AI Workflows. Erfassen Sie Modellname, Anbieter, Version, Hosting, Use Case, Product Owner, Datenkategorien, Kundensichtbarkeit, Geografie, Fine-Tuning und ob Kunden die Outputs in eigenen Workflows nutzen.

Das Inventar gehoert in Product Intake und Vendor Review. Neue AI Features, Anbieterwechsel, Modell-Upgrades, neue Datenkategorien oder EU Launches sollten denselben Eintrag aktualisieren.

Rolle vor Pflicht diskutieren

Die wichtigste Frage ist nicht sofort "gilt der AI Act?", sondern: Sind wir Modellanbieter, Downstream Provider eines AI Systems, Deployer, Distributor oder Kunde eines Vendor Features? Artikel 53 und 55 betreffen Anbieter von General-Purpose AI Modellen. Ein SaaS-Team kann aber andere Pflichten oder Kundenerwartungen haben.

Der Rollenvermerk sollte erklaeren, wer das Modell oder AI System auf den Markt bringt, wer es kontrolliert, wer es veraendert, wer den Zweck bestimmt, wer Outputs sieht und wer Verhalten aendern kann. Bei Fine-Tuning, Redistribution oder Packaging sollte Legal pruefen, ob das Unternehmen naeher an Modellanbieterpflichten rueckt.

Trigger klar definieren

Review sollte ausgeloest werden, wenn ein neues Modell eingefuehrt wird, Anbieter oder Modellfamilie wechseln, ein Modell fine-tuned wird, Outputs kunden sichtbar werden, ein sensibler Use Case hinzukommt, Trainings- oder Logging-Einstellungen geaendert werden oder ein Anbieter systemisches Risiko meldet. Das Ergebnis sollte "genehmigt", "genehmigt mit Bedingungen", "blockiert" oder "mehr Fakten noetig" sein.

Evidence Packet bauen

Ein schlankes Evidence Packet enthaelt Inventar, Rollenmap, Use Case, Anbieter, Modellversion, Hosting, Datenkategorien, Kundensichtbarkeit, erlaubte und verbotene Nutzung, Vendor-Dokumentation, Privacy Review, Security Review, Logging, Monitoring, Change Process, Fallback Plan und Customer Disclosure Position.

Wenn das Unternehmen ein Modell bereitstellt oder wesentlich veraendert, gehoeren technische Dokumentation, Trainings- oder Fine-Tuning-Daten, Evaluation, Limitations, Copyright Policy, Trainingszusammenfassung, Downstream-Dokumentation, Systemic-Risk-Bewertung, Incident-Prozess und Cybersecurity hinzu.

Vendor Review auf Artikel 53 ausrichten

Auch Downstream Teams sollten Anbieter fragen, ob technische Dokumentation, Integrationsdokumentation, Copyright Policy, Trainingszusammenfassung, Capability- und Limitation Notes, Usage Restrictions, Safety Documentation und Update Notices verfuegbar sind. Fragen Sie nicht nur "seid ihr compliant?", sondern nach konkreten Nachweisen.

Security prueft Access Controls, Encryption, Logging, Incident Notice, Abuse Monitoring, Subprocessors und Hosting. Privacy prueft personenbezogene Daten, Retention, Training Settings, Transfers und DPIA-Bedarf. Product prueft Limits, Fallbacks und Kundenauswirkungen.

Systemisches Risiko separat routen

Bei systemischem Risiko nach Artikel 51 und 55 sollten Teams Anbieter direkt fragen, ob das Modell so klassifiziert ist, ob das AI Office informiert wurde, welche Safety- und Security-Nachweise verfuegbar sind und welche Aenderungen Kundennotizen ausloesen. Fuer Product ist die Kernfrage Abhaengigkeitsrisiko: Verfuegbarkeit, Policies, Limits und Incident-Pflichten koennen Produktzusagen beeinflussen.

Code of Practice nutzen

Der General-Purpose AI Code of Practice ist freiwillig, aber als Operating Reference hilfreich. Er gibt Teams Sprache fuer Transparenz, Copyright, Safety, Security, Dokumentation und Risikomanagement. Ob ein Anbieter den Code unterschreibt, ist nicht die ganze Antwort, aber ein relevanter Fakt fuer Vendor Diligence.

Kundenantworten kontrollieren

Sales und Support sollten Antworten zu Modellanbietern, Datennutzung, Training, Retention, Subprocessors, Limits, Incident Handling und Change Notices nicht improvisieren. Approved Answers sollten mit dem Evidence Packet verbunden sein. So wird Enterprise Review wiederholbar statt jedes Mal neu recherchiert.

FAQ

Was ist der praktische Zweck?

Das Team weiss, welche Modelle genutzt werden, welche Rolle das Unternehmen hat, welche Nachweise existieren und was bei Modell-, Use-Case-, Vendor- oder Rechtsaenderungen passiert.

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 oder Vendor-Beziehung nutzt.

Was zuerst dokumentieren?

Starten Sie mit Modellinventar, Rollenvermerk, Anbieterunterlagen, Use Case, Kundensichtbarkeit, Datenkategorien, Modellversion, Privacy und Security Review, Copyright Position, Limits, Monitoring und Change Trigger.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission AI Act Service Desk, Article 51.
• European Commission AI Act Service Desk, Article 53.
• European Commission AI Act Service Desk, Article 55.
• European Commission, Drawing-up a General-Purpose AI Code of Practice.