Skill Reference · Update 2026-08-17 — jetzt inkl. Art. 5 / Art. 6 / GPAI (POL-0049)

EU AI Act

Was jede:r bei Spherity über KI-Kennzeichnungspflicht, Chatbots, AI-Produkt-UX und Risikoklassifikation wissen muss · Quelle: policy_ai_product_ux, POL-0047, POL-0049, asset_website

Warum das jede:n betrifft, nicht nur Design

Spherity bietet CARO, VERA, EIDA und KYLE gewerblich Geschäftskunden an — damit gilt Spherity rechtlich als Provider und/oder Deployer eines KI-Systems nach dem EU AI Act. Das ist eine bindende gesetzliche Pflicht, keine Design-Empfehlung: Verstöße können mit Bußgeldern bis zu 15 Mio. Euro oder 3 % des weltweiten Jahresumsatzes geahndet werden.

Frist: Art. 50 gilt seit 2. August 2026. Die Transparenzpflichten aus Artikel 50 der KI-Verordnung sind bereits in Kraft. Vier Bereiche sind im Gesetz benannt: (1) direkte Interaktion mit einer natürlichen Person offenlegen, (2) KI-generierte Inhalte kennzeichnen, (3) Emotionserkennung / biometrische Kategorisierung offenlegen, (4) Deepfakes und KI-generierte Texte von öffentlichem Interesse kennzeichnen. Nur (1) und (2) sind aktuell gegen ein echtes Spherity-Feature geprüft; (3) ist nicht anwendbar — es gibt aktuell kein Emotionserkennungs- oder biometrisches Feature bei CARO/VERA/EIDA/KYLE, ehrlich benannt statt stillschweigend ausgelassen.

Diese Seite ist die Guide-Version von policy_ai_product_ux — das prüft die End-User-UX eines KI-Features in einem Spherity-Produkt (Chatbot, Assistent, KI-Content-Fläche). Das ist etwas anderes als policy_responsible_ai, das prüft, wie ein AI-Skill sich innerhalb von DesignOS selbst verhält — verwandt, aber nicht dasselbe.

Jenseits von Art. 50: Verbotene Praktiken, Hochrisiko, GPAI

Art. 50 ist die Transparenzpflicht — nicht die vollständige Risikoklassifikation. Diese Seite deckte bisher ausschließlich Art. 50 ab (die Guide-Version von policy_ai_product_ux). Die drei übrigen Bereiche des Gesetzes werden jetzt separat erfasst — in POL-0049, nicht hier dupliziert. Diese Sektion ist die Kurzfassung.

Fristen-Update (Digital Omnibus, in Kraft seit 27.07.2026): Die Hochrisiko-Pflichten aus Art. 6 wurden verschoben — Anhang III (eigenständige Systeme) von ursprünglich 2. August 2026 auf 2. Dezember 2027, Anhang I (in reguliertes Produkt eingebettet) von 2. August 2027 auf 2. August 2028. Die Prüfpflicht selbst bleibt bestehen — nur die Umsetzungsfrist hat sich verschoben. Quelle: EC AI Act Service Desk, Stand 2026-08-17 — bei jeder Anwendung neu zu bestätigen, nicht aus dieser Seite übernehmen.

Bereich	Kurzfassung	Aktuell für Spherity
Art. 5 — Verbotene Praktiken	Manipulation, Ausnutzung von Vulnerabilitäten, Social Scoring, verbotene Biometrie/Emotionserkennung, nicht-einvernehmliche intime Bildinhalte/CSAM.	Kein bekannter Treffer bei CARO/VERA/EIDA/KYLE — Feststellung, kein Freibrief. Jedes neue Feature wird geprüft.
Art. 6 / Anhang I+III — Hochrisiko	Eigenständige Hochrisiko-Systeme (Anhang III) bzw. Sicherheitsbauteile in regulierten Produkten (Anhang I).	Näheprüfung zu „wesentlichen Dienstleistungen" pro Produkt-Feature ausstehend — nicht pauschal für die Produktsuite.
GPAI	Gilt primär für Anbieter von General-Purpose-AI-Modellen (Claude, GPT, Gemini, …).	Spherity ist Nutzer, nicht automatisch Provider — wird pro Integration bestätigt, nie angenommen.

Vollständige Prüflogik, Eskalationsregeln und Registry-Pflicht: POL-0049 (Status: draft, noch kein Sign-off). Jedes KI-System wird vor Produktivbetrieb in der AI System Registry (10_Governance/Registries/AISystemRegistry.md) erfasst — aktuell noch ohne befüllte Einträge. Nicht zu verwechseln mit AIRegistry.md, das regelt, wie AI Skills sich innerhalb von DesignOS verhalten, nicht ein System-Inventar.

Kennzeichnung / Disclosure

Zwei gesetzlich bindende Hard-Refuse-Regeln, keine Ausnahme möglich, sobald das Gesetz in Kraft ist:

Hard-Refuse · ai_self_disclosure

Jedes KI-gestützte Chat- oder Assistenz-Feature muss sich als KI-gesteuert zu erkennen geben — über ein dauerhaftes, wahrnehmbares Label, nicht versteckt in den AGB, kein einmaliger Toast, sichtbar vor oder spätestens zu Beginn der Interaktion.

Hard-Refuse · ai_generated_content_marking

Inhalte, die ein KI-Feature erzeugt oder wesentlich verändert hat (Text, Bild, Audio, Video), müssen als KI-generiert bzw. KI-bearbeitet gekennzeichnet werden — maschinenlesbar, und überall, wo sie Nutzer:innen sichtbar sind, auch menschlich wahrnehmbar. Verbindlich, bevor solcher Inhalt an einer Stelle veröffentlicht wird, die die Öffentlichkeit zu einer Sache von öffentlichem Interesse informieren könnte, und bevor Deepfake-artiger Inhalt einer Person erstmals gezeigt wird.

Regel: voll oder wesentlich KI-erzeugt = kennzeichnen. Rein assistive Bearbeitung (z. B. Farbkorrektur an einem echten Foto) = nicht. Graubereich = im Zweifel kennzeichnen.

Bereits konkret umgesetzt: KI-Bild-Kennzeichnung auf spherity.com

Entschieden 2026-08 (asset_website): KI-erzeugte Bilder auf der Website tragen zwei Markierungen — maschinenlesbar (C2PA + IPTC DigitalSourceType) und sichtbar (component_web_ai_disclosure). Drei sichtbare Varianten sind sanktioniert: Corner-Pill (Default, neutral, nie in einer Key Color), Caption-Zeile (redaktionell), Provenance-Chip (nur wenn Herkunftsdaten vorliegen). Bilder reservieren am unteren Rand Safe-Space, damit das Label keinen Inhalt überlagert. Siehe ADR-0018.

Chatbot-Regeln (Gleap)

Spheritys KI-Chat-Features laufen auf Gleap, mit bereits real benannten Personas pro Produkt. Vier Hard-Refuse-Regeln, distilliert aus dem internen „Gleap Chat Bots"-Notion-Ticket (Status „Ready for review", Projekt „Using AI at Spherity") — erstmals gegen eine echte, ausgelieferte Chatbot-Implementierung geprüft am 11.08.2026.

Regel	Was das bedeutet
Ein einziger Einstiegspunkt ai_chat_single_entry_point	Ein KI-Chat-Feature wird nur über sein eigenes, standardisiertes Widget ausgelöst — nie über einen eigens platzierten Button anderswo im Produkt oder auf der Website. Ein eigener Trigger umgeht sonst Disclosure-Label, Avatar und Opener-Message des Standard-Einstiegspunkts.
Visuelle Identität ai_chat_visual_identity	Der Avatar ist immer Spheritys eigenes „S"-Logo-Zeichen — nie ein menschliches Gesicht, ein generisches Chat-Icon oder der Standard-Avatar eines Drittanbieter-Tools.
Persona statt Anbietername ai_chat_persona_not_vendor_name	Ein KI-Chat-Feature stellt sich unter seiner Spherity-Persona vor — Caroline für CARO, Veronica für VERA — nie unter dem Namen des zugrunde liegenden Anbieters (Gleap). EIDAs Persona-Name ist noch nicht vergeben — ein echter, offener Punkt, siehe `ActionList.md`.
Kein stiller Ausfall ai_chat_graceful_unavailability	Kann das Feature nicht antworten (Modell nicht verfügbar, Budget erschöpft, Anfrage außerhalb des Scopes), zeigt das Widget eine definierte, zur Persona passende Fallback-Nachricht und einen Weg zum menschlichen Support. Es darf nie kommentarlos verschwinden, still fehlschlagen oder Nutzer:innen mitten im Gespräch ohne Erklärung zurücklassen.

Weitere Regeln (Warning-Level, aus NN/G-Forschung)

Vier Regeln, nicht gesetzlich vorgeschrieben, aber Reviewer-Judgment-Pflicht — distilliert aus Nielsen-Norman-Group-Research zu AI-UX:

Rollen-kalibrierte Erklärbarkeit. Wo eine KI-Ausgabe eine Entscheidung materiell beeinflusst (ein Compliance-Flag, ein Verifikationsergebnis, ein Risk-Score), muss das Interface die betroffene Rolle sehen lassen, warum — passend zu dieser Rolle, nicht ein generischer Tooltip für jedes Publikum.
Unsicherheit sichtbar machen. Ein KI-Feature zeigt seine eigene Unsicherheit, statt jede Ausgabe mit gleichbleibender Sicherheit zu präsentieren — Confidence-Level, vorsichtige Sprache oder eine prüfbare Quellenangabe, überall wo das Modell plausibel falsch liegen kann, ohne dass ein sichtbares Signal dafür existiert.
Mensch bleibt im Loop. KI-generierter Inhalt oder eine KI-Entscheidung muss von der Nutzerin überprüfbar, editierbar und umkehrbar sein, bevor sie auf etwas Konsequenzhaftes wirkt (ein eingereichtes Dokument, ein geteiltes Credential, ein Compliance-Record). Ein KI-Feature committet nie automatisch eine konsequenzhafte Aktion ohne explizite menschliche Bestätigung.
Kompetenz statt Persönlichkeit. Interface und Copy eines KI-Features bauen Vertrauen über demonstrierte Kompetenz und Vorhersagbarkeit auf — nicht über simulierte Persönlichkeit, emotionale Sprache oder anthropomorphe Rahmung, die keine echte Fähigkeit dahinter hat.
Direkte Antwort zuerst. Die Standard-Antwort eines KI-Assistenten beantwortet die Anfrage direkt, bevor sie zusätzlichen Kontext anbietet — keine ungefragte Ausschmückung einer kurzen Antwort, nur um hilfreicher zu wirken.
Gefühlte Latenz. Wo das zugrunde liegende Modell es unterstützt, streamt eine KI-Antwort inkrementell statt erst komplett fertig zu erscheinen, sobald die volle Antwort voraussichtlich länger als etwa eine Sekunde dauert.

Eskalation & Ticket-Logging — verpflichtend, nicht optional

Jeder bekannte Verstoß gegen ai_self_disclosure oder ai_generated_content_marking — ein Chatbot ohne Disclosure-Label, unmarkiert veröffentlichter KI-Entwurf — wird sofort an role_design_experience_lead eskaliert, oder, wo der Verstoß eine Sicherheits- oder Datenverarbeitungs-Dimension hat, an Information Security (IS) gemeldet, die ab diesem Punkt ihren eigenen, hier nicht modellierten Workflow durchläuft. Nie still gelöst, nie auf ein späteres Release verschoben.

Stammt der Prototyp aus einem Notion-Ticket, wird der Verstoß zusätzlich in genau diesem Ticket dokumentiert — nicht nur mündlich eskaliert. Existiert noch kein Ticket, wird eines über den unternehmenseigenen ticketing-Skill erstellt, bevor der Prototyp weitergeht.

Betrifft der Verstoß stattdessen eine Rechtsfrage nach Art. 5, Art. 6 oder GPAI (POL-0049, nicht Art. 50), läuft die Eskalation über role_legal — seit 2026-08-17 als eigene Rolle benannt (07_Roles/role_legal.md). Vorher war role_legal in POL-0047 als Eskalationsziel benannt, ohne dass die Rolle selbst irgendwo definiert war.

Offene Punkte — ehrlich benannt

EIDAs Chat-Persona ist noch nicht benannt. Caroline (CARO) und Veronica (VERA) existieren bereits real; EIDA fehlt noch — ein echter, offener Punkt, kein Versehen.
Vollständiger Compliance-Check gegen die live laufenden Bots steht noch aus. Diese Seite dokumentiert die Regeln; ob jeder aktuell ausgelieferte Chatbot sie tatsächlich erfüllt, ist noch nicht geprüft.
KYLE-Chat-Rollout ist an dieser Stelle nicht gesondert dokumentiert — bei Bedarf gegen policy_ai_product_ux direkt prüfen.
Art. 6/Anhang I+III-Klassifikation pro Produkt-Feature ist noch nicht durchgeführt. POL-0049 definiert seit heute die Prüfmethode, nicht das Ergebnis — der erste reale Klassifikationslauf für CARO/VERA/EIDA/KYLE steht noch aus.
AI System Registry existiert nur als Schema, noch ohne einen einzigen befüllten Eintrag. 10_Governance/Registries/AISystemRegistry.md ist angelegt; der erste reale Eintrag (z. B. der Gleap-Chatbot) fehlt noch.
POL-0049 und die AI System Registry haben Status draft. Kein Sign-off durch role_design_experience_lead + role_legal bisher — diese Seite dokumentiert einen Vorschlag, keine bereits akzeptierte Policy.

Review-Fragen

Legt dieses KI-Feature offen, dass es KI ist — vor oder spätestens zu Beginn der Interaktion, nicht versteckt, nicht verzögert?
Kann die Nutzerin diese KI-Ausgabe sehen, editieren oder rückgängig machen, bevor sie etwas Konsequenzhaftes bewirkt?
Zeigt das Interface Unsicherheit, wo das Modell plausibel falsch liegen könnte, oder präsentiert es jede Antwort mit derselben Sicherheit?
Nutzt das Chat-Feature ausschließlich seinen eigenen Standard-Einstiegspunkt, seine Spherity-Persona und seinen S-Mark-Avatar — nie einen eigenen Trigger-Button oder die Identität des Anbieters?
Wurde für dieses KI-System/-Feature schon einmal geprüft, ob es unter Art. 5 (verboten) oder Art. 6/Anhang I+III (Hochrisiko) fällt — oder wurde nur Art. 50 geprüft und stillschweigend als „das reicht" behandelt?
Hat dieses KI-System bereits einen Eintrag in der AI System Registry, oder läuft es ohne einen?

Querverweise: Ethical Design · Guardrails · AI Behavior