Sicherheit und verantwortungsvolle KI
HumAIn Labs entwickelt und betreibt KI-Agenten nach öffentlich zugänglichen, anerkannten Sicherheits- und Steuerungsrahmenwerken. Unten beschreiben wir, nach welchen Rahmenwerken wir bauen, wie sie in die Kontrollen des einzelnen Setups übersetzt werden, und was wir nicht behaupten.
Ein KI-Agent unterscheidet sich von einer gewöhnlichen Anwendung dadurch, dass er Entscheidungen trifft und Handlungen in mehreren Schritten ausführt. Das macht den Agenten brauchbar — und verschiebt einen Teil des Risikobildes vom Modell auf die Art, wie der Agent in die Welt gesetzt ist: welche Werkzeuge er hat, welche Rechte er hat, was er erreichen kann und wer ihn stoppen kann.
Deshalb behandeln wir Sicherheit als Eigenschaft der Einrichtung, nicht als Filter über dem Modell. Jedes Setup wird beschrieben, gemessen und freigegeben, bevor es in Betrieb geht.
| Rahmenwerk | Typ | Verwendung bei HumAIn Labs |
|---|---|---|
| OWASP Top 10 for Agentic Applications 2026 | Offener Kontrollkatalog (OWASP GenAI Security Project, Dezember 2025) | Der operative Risikokatalog. Die zehn Risikokategorien ASI01–ASI10 werden in konkrete, überprüfbare Kontrollen in unseren Setups übersetzt. |
| NIST AI Risk Management Framework 1.0 mit Generative AI Profile (NIST AI 600-1) |
Amerikanisches Standardrahmenwerk (NIST) | Die Struktur für Risikomanagement: Govern, Map, Measure, Manage. Wir nutzen sie, um Rollen, Risikobewertung, Messung und laufende Nachverfolgung festzuhalten. |
| ISO/IEC 42001:2023 | Internationale Norm für KI-Managementsysteme (AIMS) | Referenzrahmen für Steuerungsdokumentation, Verantwortung, Risikoregister und interne Kontrolle. HumAIn Labs ist nicht nach ISO/IEC 42001 zertifiziert. |
| KI-Verordnung der EU (2024/1689) | Rechtsvorschrift | Wir gestalten die Lösungen auf Konformität hin, einschließlich Transparenz- und Dokumentationspflichten. Die Einstufung des einzelnen Systems erfolgt gemeinsam mit dem Kunden vor der Inbetriebnahme. |
Zur Zertifizierung: Die Rahmenwerke dienen als Kontrollkatalog und Steuerungsmodell — nicht als Qualitätssiegel. Wir nennen ein System erst zertifiziert, wenn eine akkreditierte Zertifizierungsstelle es erklärt hat.
Kein Agent, kein Profil, keine Integration und keine geplante Aufgabe geht in Betrieb, ohne unsere Sicherheitsprüfung durchlaufen zu haben. Die Prüfung ist maschinell und wiederholbar: Sie liest die tatsächliche Konfiguration, nicht eine Beschreibung davon. Das Ergebnis ist einer von drei Zuständen:
Die Prüfung wird bei Änderungen an Konfiguration, Werkzeugen oder Rechten erneut ausgeführt — und als fester Teil der laufenden Überwachung.
Wenn ein Agent ein Programm bedienen soll, gibt es zwei Wege. Den tiefen: Integration über die API des Programms, seine Datenbank oder ein Plugin. Und den flachen: der Agent bedient das Bildschirmbild des Programms — er sieht, klickt und tippt, wie ein Mensch es täte.
Wir wählen in der Regel den flachen Weg. Das bedeutet, dass wir keine Schlüssel zu den Systemen des Kunden brauchen, nichts an seiner Einrichtung ändern und keinen Zugriff auf Daten in dahinterliegenden Datenbanken haben. Der Agent kann, was der Benutzer mit denselben Rechten kann — nicht mehr.
Der Preis für diesen Ansatz ist, dass der Agent davon abhängt, dass das Bildschirmbild so aussieht wie erwartet. Ändert sich das Programm, hält der Agent an und löst ein Ereignis aus, statt auf Verdacht weiterzumachen. Die tiefe Integration bleibt die richtige Wahl, wenn die Aufgabe große Datenmengen oder hohe Geschwindigkeit verlangt — wir wählen sie, wenn sie die bessere ist, und sagen es laut, wenn sie es ist.
Ein Agent, der nie stoppt, ist kein starker Agent — er ist ein Risiko. Unsere Agenten arbeiten deshalb mit einem definierten Stoppunkt (HARM) und mit einer Autonomie, die erworben werden muss.
Kein Agent erhält vom ersten Tag an freie Hand. Das Recht, selbst zu handeln, entsteht aus dokumentierter Treffsicherheit: Eine vereinbarte Anzahl bestandener Prüfungen in Folge hebt die Stufe, und ein abgelehntes Ergebnis senkt sie und gibt den Fall an einen Menschen. Die Grenzen gelten auf allen Stufen, auch bei höchster Autonomie.
Der Kontrollkatalog deckt die zehn Risikokategorien der OWASP-Agentenliste ab. Jede Kontrolle hat ein messbares Kriterium und einen erfassten Status.
| Bereich | Was geprüft wird |
|---|---|
| Zugriffsrechte | Dass der Agent nur die Rechte hat, die die Aufgabe erfordert — und dass vorab freigegebene Befehle minimiert sind. |
| Werkzeugbegrenzung | Dass eine Einschränkung tatsächlich aktiv ist, nicht nur beschrieben. Eine Beschränkung, die nicht greift, zählt nicht. |
| Umgang mit Geheimnissen | Dass Schlüssel und Tokens nicht im Klartext in Konfigurationen liegen, die zwischen Profilen geteilt werden. |
| Kontrollfläche | Dass Administration und Freigaben nur aus dem vorgesehenen Netzwerk erreichbar sind. |
| Lieferkette | Dass Plugins, Hooks und Integrationen versionsgebunden sind und im Betrieb keinen Code nachladen und ausführen. |
| Isolation des Gedächtnisses | Dass jeder Nutzer und jede Rolle ein eigenes Gedächtnis hat, damit ein Kontext einen anderen nicht vergiften kann. |
| Menschliche Freigabe | Dass Freigaben einen Menschen erfordern — auch wenn der Agent geplant läuft. |
| Netzwerkexposition | Dass Dienste, die breit lauschen, bekannt, notwendig und akzeptiert sind. |
| Geplante Aufgaben | Dass autonome Läufe eine Werkzeuggrenze haben und dass externe Inhalte nicht mit Codeausführung kombiniert werden. |
| Integrationen | Dass Datenverbindungen lokal oder freigegeben sind und kein unerwünschter Datenaustausch entsteht. |
Sicherheit, die nicht überprüft werden kann, ist eine Absichtserklärung. Zur Lieferung gehört deshalb Dokumentation, die der Kunde oder Dritte durchsehen kann:
Wir gehen Kontrollen und Dokumentation für Ihr konkretes System gerne durch.