Richtlinie zu Data Governance, Risiko und Compliance
IuVeAI / iuve.eu
Version: 1.0
Datum des Inkrafttretens: 26 August 2026
Dienst: https://www.iuve.eu/
Betreiber
Projektentwickler: Iurie Verejan
Legal Company / Betreiber: RECLAMA-VEREJAN I.I.
DNO/Code: 1003600053323
Anschrift: MD-2042, Moldova, CHISINAU CIOCANA, mun. Chisinau, Alecu Russo, 24/2
Unterstützung: hello@iuve.eu
Diese Data Governance, Risk & Compliance Policy („DGRC Policy) ergänzt die Datenschutzpolitik, Nutzungsbedingungen, Cookie-Politik, Acceptable Use Policy, und AI und Model Training PolicyWenn eine spezifischere Politik einen strengeren Schutz vorsieht, gilt die strengere Anforderung, sofern sie nicht gesetzlich verboten ist. Diese Richtlinie ersetzt nicht die Datenschutzrichtlinie für Verfahren für Datensubjektrechte.
1. Zweck
Diese DGRC-Richtlinie legt den Governance-Rahmen fest, der von IuVeAI verwendet wird, um Benutzer- und Arbeitsbereichsdaten zu verwalten; Systeme und Modelle der künstlichen Intelligenz; Anbieter von KI-Modellen; lokale und Cloud-Inferenz; API-Integrationen; autonome und semi-autonome Agenten; verbundene Geräte; Zugriffsberechtigungen; Sicherheitsrisiken; Modell- und Betriebsrisiken; Auditierbarkeit; und rechtliche und regulatorische Compliance.
Ziel ist es, sicherzustellen, dass IuVeAI gemäß Datenschutz, Sicherheit, Rechenschaftspflicht, Transparenz, Datenminimierung, menschlicher Kontrolle und risikoproportionaler KI-Governance arbeitet.
2. Anwendungsbereich
Diese Richtlinie gilt für IuVeAI-Dienste und -Komponenten, die über iuve.eu betrieben werden oder damit verbunden sind, einschließlich IuVeAI Chat; des Assistenten Iulia AI; der Weiterleitung und Inferenz von KI-Modellen; lokaler KI-Modelle; externer KI-Anbieter; des API-Zugriffs; der Datei- und Dokumentverarbeitung; der Spracheingabe und -ausgabe; STT und TTS; GitHub-Integrationen; Repositories und Programmierwerkzeuge; IuVe Connect; Desktop Agent; Avatar und lokaler Automatisierung; der Gerätekopplung; Semantic Marketing; Website Agent; Marketplace-Integrationen; Genesis CMS-KI-Integrationen; Team-Arbeitsbereiche; Verwaltungssysteme sowie Überwachungs- und Sicherheitssysteme.
Es gilt für Administratoren, Entwickler, Mitarbeiter, Auftragnehmer, Dienstleister, KI-Agenten und automatisierte Prozesse, die auf IuVeAI-gesteuerte Systeme oder Daten zugreifen.
3. Governance-Grundsätze
3.1 Privatsphäre durch Default
Private Workspace-Informationen müssen standardmäßig privat bleiben. Der Zugriff darf nur erfolgen, wenn dies zur Bereitstellung einer vom Benutzer angeforderten Funktion, zur Aufrechterhaltung der Systemsicherheit, zur Einhaltung des Gesetzes oder zur Durchführung einer ausdrücklich genehmigten Verwaltungsmaßnahme erforderlich ist.
3.2 Datenminimierung
Nur Informationen, die für den angeforderten Vorgang nach vernünftigem Ermessen erforderlich sind, dürfen gesammelt, übermittelt oder aufbewahrt werden.
3.3 Zweckbeschränkung
Für einen bestimmten Zweck gesammelte Informationen dürfen nicht automatisch für einen anderen Zweck wiederverwendet werden.
3.4 Geringstes Privileg
Benutzer, Dienste, API-Schlüssel, Agenten und Administratoren dürfen nur die Berechtigungen erhalten, die für ihre Aufgabe erforderlich sind.
3.5 Explizite Behörde
Ein KI-Agent gewinnt keine Autorität, nur weil er eine Aktion technisch ausführen kann. Die Berechtigung muss von Benutzerberechtigungen, Arbeitsbereichskonfigurationen, Administratorrichtlinien, einer genehmigten Berechtigungsvergabe oder einer anderen dokumentierten Quelle für Berechtigungen abgeleitet werden.
3.6 Menschliche Kontrolle
Maßnahmen, die erhebliche finanzielle, rechtliche, sicherheits-, datenschutz- oder operative auswirkungen haben können, müssen weiterhin einer angemessenen menschlichen kontrolle unterliegen.
3.7 Rückverfolgbarkeit
Sicherheitssensible und agentenausgeführte Operationen sollten einem Benutzer, Dienst, API-Schlüssel, Modell, Agent oder Systemprozess zuzurechnen sein.
3.8 Fail Secure
Wenn Identität, Autorität, Politik oder Ausführungsstatus nicht zuverlässig bestimmt werden können, sollte das System standardmäßig in den sichereren Zustand versetzt werden.
4. Datenklassifizierung
IuVeAI verwendet vier primäre Datenklassifikationen.
PUBLIC
Informationen, die für die Veröffentlichung bestimmt sind (z. B. öffentliche Website-Inhalte, öffentliche Dokumentation, öffentliche Marketplace-Auflistungen und öffentliche Artikel). Öffentliche Informationen können von autorisierten IuVeAI-Systemen ohne zusätzliche Vertraulichkeitsbeschränkungen verarbeitet werden.
INTERNAL
Betriebsinformationen, die nicht zur uneingeschränkten Veröffentlichung bestimmt sind (z. B. interne Metriken, Systemkonfiguration, nicht sensible Betriebsprotokolle und interne Dokumentation). Der Zugang sollte auf zugelassene Systeme und Personal beschränkt werden.
CONFIDENTIAL
Informationen, die mit einem Benutzer, einem Arbeitsbereich, einer Organisation oder einer privaten Aktivität verbunden sind (z. B. Gespräche, hochgeladene Dateien, Repository-Inhalte, Quellcode, private Notizen, Projektinformationen, Sprachtranskripte, Agentenausführungskontext und Kundeninformationen). Vertrauliche Daten dürfen nicht an nicht verwandte Nutzer oder Dienste weitergegeben werden.
RESTRICTED
Informationen, die den höchsten Schutz erfordern (z. B. Passwörter, private Schlüssel, Authentifizierungsgeheimnisse, Zugriffstoken, API-Geheimnisse, Sitzungsanmeldeinformationen, Wiederherstellungsanmeldeinformationen, Zahlungsauthentifizierungsinformationen und hochsensible persönliche Informationen). Eingeschränkte Informationen dürfen nicht absichtlich als KI-Trainingsdaten verwendet werden. Soweit technisch möglich, sollten eingeschränkte Informationen vor der Übermittlung an ein KI-Modell oder einen externen Anbieter erkannt, gekürzt, maskiert oder blockiert werden.
5. Governance des Datenlebenszyklus
IuVeAI regelt Daten durchweg: Sammlung → Klassifizierung → Verarbeitung → Speicherung → Zugriff → Übertragung → Aufbewahrung → Löschung.
Für jede wesentliche Kategorie von Daten sollte IuVeAI in der Lage sein zu erkennen, warum die Informationen verarbeitet werden; welcher Dienst sie verarbeitet; seine Klassifizierung; wo sie gespeichert werden; wer oder was auf sie zugreifen kann; ob sie an einen Dritten gesendet werden; geltende Aufbewahrungsregeln und Löschmechanismen.
6. Governance von KI-Modellen
Jedes in IuVeAI integrierte Modell sollte einen identifizierbaren Governance-Record haben. Der Datensatz kann Modellnamen, Version, Anbieter, Bereitstellungsort, Verwendungszweck, Fähigkeiten, bekannte Einschränkungen, Kontextgrenzen, geltende Sicherheitsbeschränkungen, Datenverarbeitungsmerkmale, Bewertungsergebnisse, Routing-Priorität und Ausweichbedingungen umfassen. Wesentliche Modelländerungen sollten versioniert und überprüfbar sein.
7. Lokale und Cloud AI Verarbeitung
IuVeAI kann lokale Modelle, selbst gehostete Infrastruktur und externe KI-Anbieter verwenden. Routing-Entscheidungen können Benutzerkonfiguration, Aufgabentyp, Modellfunktionen, Datenschutzanforderungen, Latenz, Verfügbarkeit, Kosten, Sicherheit, Kontextanforderungen, Ressourcenverfügbarkeit und Qualitätsschwellen berücksichtigen.
Wenn die lokale Verarbeitung konfiguriert oder erforderlich ist, sollte IuVeAI eine genehmigte lokale Ausführung bevorzugen, bevor private Informationen extern übertragen werden. Cloud-Fallback darf eine explizite Datenschutz- oder lokale Beschränkung nicht stillschweigend außer Kraft setzen.
8. Externe KI-Anbieter
Externe KI-Anbieter müssen als Verarbeitungsdienste von Drittanbietern behandelt werden. Vor der Verwendung in der Produktion sollte IuVeAI gegebenenfalls Datenverarbeitungsbedingungen, Aufbewahrungspraktiken, Schulungsrichtlinien, Sicherheitskontrollen, geografischen Verarbeitungsstandort, Verfügbarkeit, Modellfähigkeiten, regulatorische Implikationen und Vorfallverlauf bewerten.
Sensible Informationen dürfen nicht an einen externen KI-Anbieter übermittelt werden, nur weil dieser Anbieter eine qualitativ hochwertigere Antwort liefert. Datenschutz- und Autoritätsanforderungen haben Vorrang vor der Modellqualität.
9. Modellausbildung und kontinuierliches Lernen
Private Workspace-Informationen dürfen nicht automatisch zu Trainingsdaten werden. IuVeAI unterscheidet zwischen Inferenzdaten, operativer Telemetrie, Auswertungsdaten, genehmigten Lernbeispielen und Trainingsdatensätzen. Die Übertragung von Informationen von einer Kategorie in eine andere erfordert eine definierte rechtliche und technische Grundlage.
Community- oder Produktverbesserungstraining basierend auf privaten Benutzergesprächen bleibt bestehen Opt-in, wie in der AI und Model Training PolicyDie Ablehnung der Schulung darf keine gewöhnlichen Rückschlüsse verhindern, die für die Bereitstellung des angeforderten KI-Dienstes erforderlich sind. Eingeschränkte Informationen dürfen nicht in Schulungsdatensätze aufgenommen werden.
10. Governance für kontinuierliches Lernen
Automatisierte oder kontinuierlich lernende Systeme dürfen das Produktionsverhalten ohne kontrollierte Validierung nicht direkt verändern. Ein Lern-Lebenszyklus sollte folgen: Capture → Sanitise → Evaluate → Train → Test → Canary → Verify → Approve → Deploy.
Der Trainingserfolg allein reicht für den Produktionseinsatz nicht aus. Ein neues Modell, Adapter, Regel oder erlerntes Verhalten muss vor der Aktivierung der Produktion geltende Qualitäts-, Sicherheits- und Regressionsgatter passieren. Ein Rollback der Produktion muss möglich bleiben.
11. Governance von KI-Agenten
IuVe Connect, Desktop Agent, Avatar und andere Agenten arbeiten unter expliziten Funktionen. Agenten dürfen keine uneingeschränkte Geräte- oder Kontokontrolle übernehmen. Leistungskategorien können Dateizugriff, Anwendungssteuerung, Browserinteraktion, Terminalausführung, Repository-Zugriff, Netzwerkaktionen, Systemkonfiguration, Zwischenablagezugriff und externe Kommunikation umfassen. Die Fähigkeiten müssen durch Benutzer- oder Administratorzuschüsse begrenzt sein. High-Impact-Funktionen sollten den Widerruf und die Protokollierung von Audits unterstützen.
12. Einstufung als Agenten
Ebene 0 — Nur lesen (Inspektion, Suche, Analyse, Zusammenfassung): normalerweise ohne zusätzliche Bestätigung ausführbar, wenn bereits autorisiert.
Ebene 1 — Reversibel (Erstellen eines Entwurfs, Erstellen einer temporären Datei, Ändern des reversiblen Anwendungszustands): kann unter einer genehmigten Fähigkeitserteilung ausgeführt werden.
Ebene 2 — Wesentliche Änderung (Projektdateien ändern, Software bereitstellen, Konfiguration ändern, Produktionsressourcen aktualisieren): erfordert eine stärkere Überprüfung der Behörden und angemessene Sicherheitsvorkehrungen.
Ebene 3 — Hohe Auswirkungen (Wichtige Daten löschen, Finanztransaktionen versenden, Anmeldeinformationen offenlegen, Sicherheitsrichtlinien ändern, administrative Privilegien gewähren, irreversible Operationen durchführen): darf nicht nur deshalb ausgeführt werden, weil ein KI-Modell die Aktion empfiehlt. Zusätzliche menschliche Genehmigung oder eine ausdrücklich vorab genehmigte Politik ist erforderlich.
13. Trennung von Argumentation und Autorität
AI-generiertes Denken ist beratend. Eine Modellantwort stellt selbst keine Berechtigung dar. Die Ausführungsschicht muss die Akteursidentität, die Fähigkeitsvergabe, die Richtlinie, den Ausführungsumfang, die Umgebung und die geltenden Sicherheitsbeschränkungen unabhängig überprüfen.
14. Menschliche Aufsicht
IuVeAI muss eine sinnvolle menschliche Aufsicht über wesentliche automatisierte Entscheidungen bewahren. Die Nutzer sollten, soweit technisch anwendbar, in der Lage sein, vorgeschlagene Aktionen zu überprüfen, Aktionen abzulehnen, Berechtigungen zu widerrufen, einen Agenten zu stoppen, Ausführungsergebnisse zu prüfen und fehlerhaftes Verhalten zu melden.
15. AI-Transparenz
Benutzer müssen in der Lage sein zu verstehen, wenn sie mit einem KI-System und nicht mit einem Menschen interagieren. Sofern dies nach geltendem Recht erforderlich und technisch angemessen ist, müssen KI-generierte oder KI-manipulierte Inhalte eine angemessene Offenlegung oder maschinenlesbare Identifizierung unterstützen. IuVeAI darf nicht absichtlich ein künstliches System als menschliches Individuum darstellen, wenn dies den Benutzer wesentlich irreführen würde.
16. Risikoreiche und verbotene Verwendungen
IuVeAI muss zusätzliche Kontrollen für KI-Anwendungen anwenden, die sich wesentlich auf Beschäftigung, Kredit, Versicherung, Gesundheitswesen, gesetzliche Rechte, biometrische Identifizierung, öffentliche Dienste, kritische Infrastruktur, Strafverfolgung oder finanzielle Vermögenswerte auswirken können. Funktionen, die in geregelte oder verbotene Kategorien fallen, müssen vor dem Einsatz einer spezifischen rechtlichen und Risikobewertung unterzogen werden. Die Verfügbarkeit eines leistungsfähigen Modells erlaubt eine solche Verwendung nicht automatisch.
17. Automatisierte Entscheidungsfindung
Wenn ein KI-System bei Folgeentscheidungen hilft, sollte das System klar zwischen Informationsabruf, Empfehlung, Scoring, automatisierter Entscheidung und Ausführung unterscheiden. Soweit gesetzlich vorgeschrieben, müssen die Nutzer Zugang zu einer menschlichen Überprüfung oder einem anderen geeigneten Anfechtbarkeitsmechanismus haben.
18. Governance im Bereich Sicherheit
IuVeAI wendet risikobasierte Sicherheitskontrollen an, die gegebenenfalls Folgendes umfassen: Verschlüsselungstransit, sicheres Passwort-Hashing, API-Key-Schutz, geheime Trennung, Authentifizierung, rollenbasierte Zugriffskontrolle, Ratenbegrenzung, Sitzungsschutz, Auditprotokollierung, Abhängigkeitsmanagement, Schwachstellenbeseitigung, Backups, Wiederherstellungskontrollen und Serviceüberwachung. Sicherheitskontrollen müssen regelmäßig gegen Änderungen in der Architektur und Bedrohungsmodellen überprüft werden.
19. Verwaltung von Geheimnissen
Geheimnisse dürfen nicht direkt in öffentlichen Repositories, Frontend-Javascript, öffentlichen Protokollen, Trainingsdatensätzen, Analyse-Nutzlasten oder gewöhnlichem Chat-Verlauf gespeichert werden. API-Schlüssel und Anmeldeinformationen sollten bereichert, widerrufbar und nach Zweck getrennt sein. IuVe Marketplace Lizenzschlüssel ()mp_live_*) und IuVeAI API Anmeldeinformationen (kai_live_*muss logisch getrennt bleiben.
20. Zugriffsgovernance
Zugangsentscheidungen sollten auf authentifizierter Identität und Rolle basieren. Privilegierter Zugang sollte folgen: Identität → Authentifizierung → Rolle → Umfang → Politik → Aktion. Der administrative Zugang darf nicht ausschließlich durch den Besitz einer öffentlichen Kennung gewährt werden. Privilegierte Aktionen sollten überprüfbar sein.
21. Integrationen Dritter
Angeschlossene Dienste wie GitHub und externe APIs müssen nur mit Berechtigungen arbeiten, die für die angeforderte Funktionalität erforderlich sind. Integrationsnachweise müssen widerrufbar sein. Das Entfernen einer Integration sollte den zukünftigen Zugriff wo immer technisch möglich beenden. Die Integration von Drittanbietern gewährt IuVeAI kein Eigentum an Inhalten von Drittanbietern.
22. Datenübermittlung
Wenn persönliche oder vertrauliche Informationen an einen Dritten oder eine andere Gerichtsbarkeit übertragen werden, sollte IuVeAI die geltenden Datenschutz- und Vertragsanforderungen bewerten. Erforderlichenfalls müssen vor der Überstellung geeignete Sicherheitsmaßnahmen getroffen werden.
23. Protokollierung und Audit
IuVeAI kann Aufzeichnungen über Sicherheits- und Betriebsaudits führen, die erforderlich sind, um festzustellen, wer eine Maßnahme durchgeführt hat, welcher Dienst oder Agent sie ausgeführt hat, wann sie stattgefunden hat, welche Fähigkeit genutzt wurde, ob die Maßnahme erfolgreich war, ob eine Genehmigung erforderlich war und welche relevanten Sicherheitsereignisse erforderlich sind. Die Auditprotokolle selbst müssen vor unbefugten Änderungen und Offenlegungen geschützt sein. Protokolle sollten nicht unnötigerweise vollständige Geheimnisse oder vertrauliche Nutzlasten enthalten.
24. Risikomanagement
IuVeAI verwendet einen risikobasierten Ansatz. Zu den Risiken können Datenschutzrisiken, Cybersicherheitsrisiken, Modellhalluzinationen, sofortige Injektionen, Datenlecks, Privilegeskalation, böswillige Tool-Nutzung, Kompromisse in der Lieferkette, Anbieterausfall, Modellabbau, fehlerhafte autonome Maßnahmen, regulatorische Risiken und Reputationsrisiken gehören. Das Risiko wird nach Wahrscheinlichkeit × Auswirkung × Exposition bewertet. Die Kontrollen sollten proportional zum daraus resultierenden Risiko sein.
25. AI-Risikoregister
Wesentliche KI-Komponenten sollten in einem internen KI-Risikoregister vertreten sein. Jeder Datensatz kann System, Eigentümer, Modell, Zweck, betroffene Benutzer, Datenkategorien, Risikoklassifizierung, bekannte Risiken, Minderung, Bewertungsstatus, Bereitstellungsstatus und Überprüfungsdatum enthalten.
26. Datenschutzfolgenabschätzung
Vor der Bereitstellung von Funktionen, die das Risiko für Einzelpersonen erheblich erhöhen könnten, sollte eine Datenschutz- oder KI-Risikobewertung durchgeführt werden, einschließlich umfangreicher Profilerstellung, biometrischer Verarbeitung, sensibler personenbezogener Daten, automatisierter Folgeentscheidungen, kontinuierlicher Überwachung oder erheblicher neuer Datenübertragungen durch Dritte.
27. Sicherheitsvorfallmanagement
Ein Verdacht auf Sicherheits- oder Datenschutzvorfall muss: Detected → Contained → Investigated → Assessed → Remediated → Documented. Soweit gesetzlich vorgeschrieben, müssen betroffene Personen oder zuständige Behörden innerhalb der geltenden Fristen benachrichtigt werden. Die Beweise für Zwischenfälle sollten ausreichend aufbewahrt werden, um die Untersuchung zu unterstützen.
28. Management von KI-Vorfällen
KI-Vorfälle umfassen wesentliche Ereignisse mit unsicherer autonomer Ausführung, erheblicher Offenlegung vertraulicher Daten, systematischer schädlicher Ausgabe, Umgehung der Sicherheitskontrolle, Fehlfunktion des Materialmodells oder Handlungen von unbefugten Agenten. KI-Vorfälle müssen getrennt von gewöhnlichen Anwendungsfehlern bewertet werden, wenn das KI-Verhalten wesentlich zum Ereignis beigetragen hat.
29. Nutzerrechte und -kontrolle
IuVeAI sollte Mechanismen bereitstellen, die nach geltendem Datenschutzrecht erforderlich sind, damit die Nutzer relevante Rechte in Bezug auf ihre personenbezogenen Daten ausüben können, zu denen Zugang, Berichtigung, Löschung, Einschränkung, Widerspruch, Übertragbarkeit und Widerruf der Einwilligung gehören können. Eine Identitätsprüfung kann erforderlich sein, bevor eine Anfrage mit privaten Kontoinformationen erfüllt wird. Die Einzelheiten des Verfahrens sind in der Datenschutzpolitik.
30. Vorratsdatenspeicherung
Informationen sollten nicht ohne einen festgelegten Zweck auf unbestimmte Zeit gespeichert werden. Aufbewahrungsfristen können je nach Dienstfunktionalität, Kontokonfiguration, Sicherheitsanforderungen, vertraglichen Anforderungen, gesetzlichen Verpflichtungen und Benutzerlöschungsanforderungen variieren. Das Löschen von aktiven Systemen entfernt möglicherweise nicht sofort Informationen aus geschützten Backups, wenn eine vorübergehende Speicherung für die Wiederherstellung von Katastrophen technisch erforderlich ist.
31. Datenlöschung
Die Löschverfahren sollten anwendbare Kopien in Primärdatenbanken, Dateispeicherung, Konversationsspeicherung, Vektor- oder Suchindizes, Caches, abgeleitete Datensätze, Schulungskandidatendatensätze und Backups betreffen, soweit dies technisch und rechtlich angemessen ist. Das Löschen eines benutzersichtbaren Objekts sollte keine nicht offenbarte aktive Kopie hinterlassen, die für eine nicht verwandte Verarbeitung verwendet wird.
32. Einhaltungsrahmen
IuVeAI ist bestrebt, im Einklang mit den geltenden Anforderungen und anerkannten Grundsätzen zu handeln, einschließlich, soweit relevant, der EU-Datenschutzgrundverordnung, des EU-Gesetzes über künstliche Intelligenz, der geltenden moldauischen Datenschutzanforderungen, der vertraglichen Datenverarbeitungspflichten, der Grundsätze des Datenschutzes nach dem Design und der Sicherheit nach dem Design sowie der geltenden Vorschriften über geistiges Eigentum und Urheberrecht. Die Anwendbarkeit hängt von der jeweiligen Dienstleistung, Verarbeitungstätigkeit, Gerichtsbarkeit und Rolle von IuVeAI ab.
33. Beziehung zu anderen IuVe-Richtlinien
Diese DGRC-Richtlinie sollte zusammen mit der Datenschutzrichtlinie, den Nutzungsbedingungen, der Cookie-Richtlinie, der Acceptable Use Policy, der AI- und Model Training Policy, den geltenden Marketplace-Lizenzbedingungen und den produktspezifischen Richtlinien interpretiert werden.
34. Governance-Verantwortung
Der Betreiber von IuVeAI ist für die Einrichtung des Governance-Rahmens der DGRC verantwortlich. Technische Komponenten können dieses Framework automatisch durchsetzen, aber die Governance-Verantwortung kann nicht vollständig an ein KI-Modell delegiert werden. Modellanbieter, Infrastrukturanbieter und Dienste Dritter bleiben für ihre eigenen Verpflichtungen aus geltenden Vereinbarungen und Gesetzen verantwortlich.
35. Politische Durchsetzung
Verstöße gegen diese Richtlinie können zu einer Blockierung von Anfragen, einer Ablehnung von Agentenaktionen, einem Widerruf von Fähigkeiten, einem Widerruf von API-Schlüssel, einer Kontobeschränkung, einer administrativen Untersuchung, einer Serviceaussetzung oder einer Eskalation von Vorfällen führen. Die Durchsetzung sollte in einem angemessenen Verhältnis zu Schwere, Absicht und Risiko stehen.
36. Überprüfung der Politik
Diese Richtlinie muss überprüft werden, wenn signifikante Änderungen an der IuVeAI-Architektur, den KI-Anbietern, den Modellfunktionen, den Berechtigungen von Agenten, der Verarbeitung personenbezogener Daten, dem geltenden Recht oder Sicherheitsbedrohungen auftreten. Eine formelle Überprüfung sollte auch regelmäßig stattfinden, auch wenn keine größeren Änderungen festgestellt wurden.
37. Kern-DGRC-Regel
IuVeAI folgt einem übergeordneten Governance-Prinzip: Fähigkeit ist nicht gleich Befugnis.
Ein KI-System darf nur dann auf Daten zugreifen, Tools verwenden oder Aktionen ausführen, wenn die erforderlichen Identitäts-, Berechtigungs-, Richtlinien- und Risikobedingungen erfüllt sind.
Data → Authority → Policy → AI → Action → Verification → Audit
Diese Kontrollkette bildet die Grundlage für die verantwortliche KI-Ausführung innerhalb von IuVeAI.
Kontakt
Bei Fragen zu dieser Richtlinie wenden Sie sich an den Betreiber unter Verwendung der oben genannten Details oder per E-Mail hello@iuve.eu.