KI-Governance

Mit KI-Governance dokumentieren Unternehmen ihre Vorbereitung auf den EU AI Act in Connic Enterprise. Sie erfassen KI-Systeme, vorläufige Bewertungen ihrer Rolle als Anbieter oder Betreiber, Maßnahmen, eigene Transparenzhinweise nach Artikel 50 und Vorfälle. Nachweise für Audits und die Rechtsberatung lassen sich als unveränderliche Archive exportieren, die ausschließlich Metadaten enthalten.

Zusammenfassung

Connic hält Angaben zum Geltungsbereich, zur Rolle der Organisation und zu den Risiken eines KI-Systems in einer versionierten, vorläufigen Bewertung fest. Daraus werden relevante Pflichten und Maßnahmen zugeordnet; Nachweise lassen sich in Snapshots zusammenstellen. Diese Dokumentation ersetzt keine rechtliche Beurteilung. Die endgültige Einstufung, geltende Meldefristen und die Erfüllung der Meldepflichten gegenüber Behörden müssen der Kunde und seine Rechtsberatung prüfen.

Zugriff und Berechtigungen

KI-Governance ist eine Enterprise-Berechtigung. Requests an Compliance-Routen geben 403 zurück, sofern das Projekt keinen Enterprise-Plan hat. Der Zugriff innerhalb eines berechtigten Projekts wird über vier Projekt-Berechtigungen gesteuert:

Jede Änderung wird mit Akteur, Aktion und Zustand der betroffenen Ressource in das Audit Log des Projekts geschrieben.

KI-Systeme und Lebenszyklus

Ein KI-System ist ein auf ein Projekt begrenzter Datensatz für einen Use Case und unabhängig von einem einzelnen Agenten. Der Datensatz beschreibt vorgesehenen Zweck, Verantwortlichen, Regionen und betroffene Personen und wird mit den Environments, Deployments und Agenten verknüpft, die das System umsetzen. Diese Verknüpfungen grenzen Telemetrie, Offenlegungsnachweise und Incident-Referenzen ein, die dem System zugeordnet werden.

Vorläufige Bewertungen

Eine Bewertung speichert die Antworten zu Geltungsbereich, Rolle der Organisation, verbotenen Praktiken, möglichen Hochrisikoeinstufungen und Transparenzanforderungen nach Artikel 50. Die Hochrisikoprüfung umfasst Anhang I und Anhang III, Profiling und die Ausnahme nach Artikel 6 Absatz 3. Jede Version bleibt unverändert erhalten. Connic wertet die Antworten nach den festen Regeln der jeweiligen Katalogversion aus und dokumentiert die zugrunde liegende regulatorische Quelle. Das Ergebnis ist immer als vorläufig gekennzeichnet und ausdrücklich keine rechtliche Beurteilung.

Bewertungen werden nie direkt bearbeitet. Das Erfassen neuer Antworten erstellt eine neue Version, und nur die neueste Version kann genehmigt werden. Eine Genehmigung erfordert eine Begründung, mindestens eine unterstützte Betreiberrolle und eine ausdrückliche Bestätigung, falls eine Antwort als unsicher markiert wurde.

Controls

Controls werden ausschließlich aus der neuesten genehmigten Bewertung generiert. Connic ordnet jede anwendbare Pflicht einer Maßnahme zu, die im Dashboard als Control geführt wird. Sie enthält den maßgeblichen Artikel, die Begründung der Anwendbarkeit und die Zuständigkeit für die Umsetzung:

• connic: Die Plattform stellt den Mechanismus bereit (zum Beispiel Nachverfolgbarkeit und Logging).
• customer: Die Organisation des Kunden ist für die Pflicht verantwortlich.
• shared: Plattformfunktionen unterstützen eine Pflicht, für die der Kunde weiterhin verantwortlich ist.
• external: Wird außerhalb der Plattform bearbeitet (zum Beispiel Konformität über eine notifizierte Stelle und Registrierung in der EU-Datenbank).

Jedes Control hat einen Status (gap, needs_evidence, configured oder not_applicable) und einen Nachweisstatus und ist mit den unterstützenden Connic-Funktionen verknüpft, etwa Runs und Traces, Logs, Approvals und Judges. Bei einer Aktualisierung werden die Maßnahmen aus der neuesten genehmigten Bewertung abgeleitet; bestehende Control-Datensätze bleiben erhalten. Um ein Control als not_applicable zu markieren, ist eine Ausnahmebegründung erforderlich.

Transparenzdokumentation nach Artikel 50

Jedes System kann eine Transparenzrichtlinie enthalten, die dokumentiert, wie die Organisation des Kunden Offenlegungen nach Artikel 50 umsetzt. Dazu gehören direkte Interaktion, Kennzeichnung synthetischer Inhalte, Deepfakes, biometrische und emotionale Nutzung sowie Texte von öffentlichem Interesse. Die Richtlinie erfasst Wortlaut, Sprach- und Regionseinstellungen, Platzierung, Häufigkeit, Anzeigemodus, kundenseitige Umsetzung und Nachweise zur Überprüfung.

Offenlegungsnachweise und Herkunft von Attestierungen

Nachweise zur Umsetzung dokumentieren, ob eine Offenlegung oder Kennzeichnung tatsächlich angezeigt oder ausgeliefert wurde, ob dies fehlgeschlagen ist oder ob eine Bestätigung fehlt. Jeder Datensatz verwendet die Herkunft customer_attestation oder upstream_attestation und erfordert Angaben zur bestätigenden Partei, einen Zeitstempel, einen Verweis auf den Nachweis und die Tatsachen, auf denen die Bestätigung beruht. Nachweise des Providers unterstützen den Kundendatensatz, übertragen jedoch nicht die Verantwortung des Kunden.

Datensätze sind idempotent: Ein wiederholter Request mit demselben Idempotency Key und Inhalt gibt den bestehenden Datensatz zurück; eine widersprüchliche Wiederverwendung wird abgelehnt. Attestierungen können jede kundenseitig verwaltete Oberfläche dokumentieren, einschließlich WebSocket-Anwendungen.

{
  "disclosure_type": "synthetic_content",
  "status": "applied",
  "provenance": {
    "source": "upstream_attestation",
    "attested_by": "Trust & Safety des Modell-Providers",
    "attested_at": "2026-07-15T09:30:00Z",
    "evidence_reference": "https://provider.example/c2pa/attestation/8f21",
    "basis": "Der Provider kennzeichnet generierte Medien mit C2PA Content Credentials."
  },
  "application_metadata": {
    "marking_method": "c2pa"
  }
}

Monitoring und Incidents

Jedes System kann einen Monitoring-Plan mit Verantwortlichem, Review-Zyklus, Signalen, Schwellenwerten und Datum für das nächste Review enthalten. Ein aktiver Plan erfordert einen Verantwortlichen, ein Datum für das nächste Review und entweder Signale oder ein dokumentiertes Monitoring-Verfahren. Fällige Reviews werden in der Übersicht angezeigt.

Incidents erfassen Zeitpunkt der Kenntnisnahme, Schweregrad, Status von Kausalzusammenhang und Meldepflicht, Korrekturmaßnahmen und Meldeverlauf. Außerdem können sie auf den betroffenen Run, das Environment oder Deployment verweisen. Um einen Incident als reported oder closed zu markieren, muss ein Nachweis der Behördenmeldung mit Zeitstempel, Empfänger oder Behörde, Kanal und externer Referenz erfasst sein.

Evidence Snapshots und Exporte

Ein Evidence Snapshot ist eine unveränderliche, ausschließlich auf Metadaten beschränkte Aufnahme des aktuellen Governance-Zustands für die ausgewählten Systeme und Environments in einem optionalen Zeitfenster. Snapshots werden über einen SHA-256-Hash einer kanonischen Serialisierung inhaltsadressiert, können weder bearbeitet noch gelöscht werden und bleiben über die gesamte Lebensdauer des Projekts erhalten. Vollständige Prompts und Modellausgaben sind bewusst ausgeschlossen.

Ein Snapshot bündelt die Systeme, ihre neuesten Bewertungen, Controls, Transparenzrichtlinien und deren Anwendungen, Monitoring-Pläne und Incidents. Außerdem enthält er Telemetrie zu Runs, Approvals und Judges, begrenzt auf die ausgewählten Kombinationen aus System, Agent und Environment. Audit Events sind auf das Projekt begrenzt und können keinem Environment exakt zugeordnet werden. Ein auf ein Environment begrenzter Export kennzeichnet die Audit-Event-Telemetrie daher als nicht verfügbar und erfasst den Grund in expliziten Metadaten zum Telemetrie-Geltungsbereich, statt eine projektweite Anzahl einzusetzen. Ein Export ohne Environment-Filter kann die projektweite Anzahl der Audit Events enthalten. Abdeckungsmetadaten erfassen Environment- und Zeitumfang, das Aufbewahrungsfenster des Plans und fehlende Nachweise.

Beim Herunterladen eines Exports wird ein ZIP-Archiv gestreamt. Es enthält einen lesbaren Bericht, eine kanonische JSON-Payload, CSV- und JSON-Dateien je Collection sowie ein Manifest mit SHA-256-Integritäts-Hashes je Datei. Die Response enthält den Inhalts-Hash des Snapshots und den Archiv-Hash als Header, damit Empfänger den Download unabhängig prüfen können. Diese Prüfsummen erkennen, ob Inhalte von den erfassten Hashes abweichen. Sie sind keine kryptografischen Signaturen, identifizieren keinen Unterzeichner, belegen nicht die Authentizität des Herausgebers und zertifizieren weder das Archiv noch seine rechtliche Eignung.

{
  "name": "Q3-Vorstandsreview",
  "system_id": "b4c3d2e1-...",
  "environment_ids": ["f9e8d7c6-..."],
  "time_from": "2026-04-01T00:00:00Z",
  "time_to": "2026-06-30T23:59:59Z"
}

API und Workflow

Sämtliche Funktionen der KI-Governance sind über die auf ein Projekt begrenzte REST API unter /v1/projects/{project_id}/compliance verfügbar. Die wichtigsten Routenfamilien sind:

• /overview: Den dokumentierten Stand der Vorbereitung über Systeme, Maßnahmen, Transparenz, Vorfälle und Monitoring zusammenfassen.
• /systems und /systems/{id}: KI-Systeme und ihre Verknüpfungen verwalten.
• /systems/{id}/assessments und .../review: vorläufige Bewertungen erfassen und genehmigen.
• /controls, /systems/{id}/controls/generate und .../refresh: Controls generieren und pflegen.
• /systems/{id}/transparency-policy und .../transparency-applications: Richtlinie nach Artikel 50 konfigurieren und Nachweise erfassen.
• /systems/{id}/monitoring-plan: Monitoring-Plan pflegen.
• /incidents und /incidents/{id}: Incident-Datensätze verwalten.
• /evidence-snapshots und /evidence-snapshots/{id}/download: Nachweise erfassen und exportieren.

Rechtliche Grenzen

Pflichtzuordnungen verweisen auf die Verordnung (EU) 2024/1689 (EU AI Act) nach Artikel. Verwende den amtlichen Text als Primärquelle. Artikelverweise in Connic weisen auf zu prüfende Pflichten hin, nicht auf Schlussfolgerungen, die Connic für den Kunden getroffen hat.