Common General-Purpose AI Modelle Fehler, die SaaS-Teams immer noch machen

General-Purpose AI Modellarbeit scheitert oft, wenn SaaS-Teams sie wie eine Begriffsfrage behandeln. Die praktische Frage lautet nicht nur, ob ein Modell leistungsfaehig oder breit einsetzbar ist. Es geht darum, wer es bereitstellt, wer es integriert, wer davon abhaengt, welche Nachweise existieren und was passiert, wenn sich Modell, Produktnutzung, Kundenzusage oder Rechtslage aendern.

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

Fehler 1: "Wir trainieren kein Modell" als ganze Antwort

Das kann stimmen, reicht aber nicht. Ein SaaS-Unternehmen kann ein AI System anbieten, das ein General-Purpose AI Modell integriert. Es kann ein AI System intern deployen, ein Modell fine-tunen oder eine Modellfunktion unter eigener Marke anbieten. Es kann auch von Nachweisen eines Modellanbieters abhaengen, um Kundenfragen zu beantworten.

Die bessere Loesung ist Rollenmapping. Erfassen Sie pro Modellfunktion, ob das Unternehmen Modellanbieter, Downstream Provider, Deployer, Distributor oder nur interner Nutzer eines Vendor Features ist. Diese Entscheidung gehoert in Product Intake, Vendor Review und Customer Trust Antworten.

Fehler 2: Modell- und Feature-Governance zu trennen

Teams dokumentieren oft das Produktfeature, aber nicht die Modellabhaengigkeit. Oder sie dokumentieren den Anbieter, aber nicht, wie das Feature im Produkt wirkt. Beides ist riskant.

Das Modellinventar sollte Modellname, Anbieter, Version, Hosting, Dokumentation, bekannte Grenzen, Update-Prozess und moegliche systemische Risiken enthalten. Der Feature Record sollte Use Case, Datenkategorien, Kundensichtbarkeit, Owner, Monitoring, Human Review und Kundenzusagen abdecken.

Fehler 3: Vendor Marketing statt Nachweise

Breite Aussagen wie "enterprise ready" oder "responsible AI" ersetzen keine Evidence. SaaS-Teams sollten Dokumentation zu Faehigkeiten, Grenzen, erlaubter Nutzung, Modellversionen, Security, Update Notices, Copyright Policy und Trainingszusammenfassung anfordern, soweit relevant.

Ohne kontrollierte Quelle beantworten Sales, Security, Legal und Product dieselben Fragen jedes Mal neu. Das fuehrt zu Widerspruechen und schwacher Audit Evidence.

Fehler 4: Open Source automatisch als einfach zu behandeln

Open-Source-Modelle koennen hilfreich sein, aber sie verschieben Verantwortung. Wer ein Modell selbst hostet, braucht Kontrollen fuer Infrastruktur, Zugriff, Versionierung, Evaluation, Monitoring, Missbrauch, Daten und Rollback. Bei Fine-Tuning kommen Datenherkunft, Privacy Basis, Tests, Limitations und Release Approval dazu.

Der AI Act behandelt Open Source differenziert. Bestimmte Dokumentationspflichten koennen eingeschraenkt sein, wenn Informationen oeffentlich verfuegbar sind. Das gilt aber nicht fuer Modelle mit systemischem Risiko. "Open Source" ist daher kein Kurzschluss.

Fehler 5: Systemisches Risiko auszublenden

Viele SaaS-Teams werden kein Modell mit systemischem Risiko bereitstellen, koennen aber davon abhaengen. Fragen Sie Anbieter direkt, ob ein Modell so eingestuft ist, welche Sicherheits- und Evaluationsnachweise verfuegbar sind, wie Incidents gemeldet werden und welche Aenderungen Kundenhinweise ausloesen.

Wenn eine kritische Funktion von einem solchen Modell abhaengt, braucht das SaaS-Team einen Plan fuer Modellupdates, Policy-Aenderungen, Verfuegbarkeit, Fallback und Kundenzusagen.

Fehler 6: Copyright und Trainingsinhalte zu vergessen

Artikel 53 umfasst auch Copyright Policy und oeffentliche Trainingszusammenfassung. Downstream Teams sollten Anbieterunterlagen, Vertragsbedingungen, Nutzungseinschraenkungen und genehmigte Kundenaussagen dokumentieren. Wenn eine Aussage nicht belegbar ist, sollte sie enger formuliert werden.

Fehler 7: Modellwechsel ausserhalb des Release-Prozesses

Modellupdates koennen Produktverhalten, Ablehnungsverhalten, Latenz, Kosten, Retention, Logging, Region oder Kundenzusagen veraendern. Definieren Sie Review Trigger: neuer Anbieter, neue Modellversion, neues AI Feature, neue Datenkategorie, regulierter Kundensektor, Fine-Tuning oder relevante Vendor Policy.

Besserer Workflow

Starten Sie mit einem Modellinventar. Erfassen Sie hosted APIs, Open-Source-Modelle, fine-tuned Modelle, Vendor AI Features, interne Tools, Copilots, Support Assistants und kundenkonfigurierbare Workflows.

Erstellen Sie dann ein kurzes Evidence Packet: Rollenhypothese, Vendor Dokumentation, Artikel-53- oder Artikel-55-Relevanz, Copyright- und Trainingshinweise, Security Evidence, Privacy Review, erlaubte und verbotene Nutzung, bekannte Grenzen, Monitoring, Incident Route, Change Trigger, Fallback und genehmigte Kundenantworten.

FAQ

Was ist der groesste Fehler?

Der groesste Fehler ist, General-Purpose AI Modelle als einmalige juristische Einstufung zu behandeln. Teams brauchen einen wiederholbaren Workflow mit Rollen, Evidence, Ownership und Re-Review Triggern.

Wann ist das fuer SaaS relevant?

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

Was zuerst dokumentieren?

Starten Sie mit Modellinventar und Rollenmap. Danach folgen Vendor Dokumentation, Modellversion, Use Case, Datenkategorien, Kundensichtbarkeit, Security, Privacy, Copyright, Limits, 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.