Modell-/Systemkarte – nori

Stand: 17.08.2026 · Status: Freigabe

Hinweis zur Adaption: nori trainiert kein eigenes Modell. Diese Karte beschreibt das System nori und die von ihm genutzten Foundation-Modelle. Aussagen zu Trainingsdaten der Foundation-Modelle verantworten deren Anbieter über deren jeweilige Model Cards (siehe Abschnitt 4).

1. Überblick

Feld	Angabe
Name	nori
Anbieter	azuma healthtech GmbH
Zweck	KI-gestützte Analyse von Quellcode gegen regulatorische/sicherheitstechnische Frameworks (z. B. BSI TR-03161, EU-CRA, OWASP ASVS).
Systemtyp	Orchestrierungs-/Agenten-Pipeline über universelle Foundation-LLMs; kein eigenes trainiertes Modell.
Ein-/Ausgabe	Eingabe: Quellcode + optionale Nachweisdokumente. Ausgabe: textuelle Findings (JSON/Markdown), Wikis, Reports, Summaries.
Modalität	Ausschließlich Text/strukturierte Daten (keine Audio/Bild/Video-Erzeugung).
Nutzerkreis	Entwickler-, Compliance- und Audit-Teams.

2. Architektur

• CLI (Azuma.Nori.Cli) – orchestriert Agenten, ruft den LLM-Provider, schreibt Ergebnisse nach .nori/.
• REST-API (Azuma.Nori.Api) – Policy-/Control-Metadaten, Findings-Abfragen, Auth.
• Admin-Dashboard (React, Azuma.Nori.Frontends.Admin) – Überblick, Annotation/Feedback.
• Agenten: Wiki-Builder (Wissensextraktion), Control-Evaluator (Bewertung gegen Control-Kriterien), Doc-Summarizer (Nachweisdokumente), Summarize/Supervisor (Zusammenfassungen).
• Provider-Abstraktion: LlmProviderFactory / ExecutorConfig (Modellwahl, Endpoint, Budget-Caps je Phase).

3. Vorgesehene Nutzung / Nicht vorgesehene Nutzung

Vorgesehen: unterstützende, vorbereitende Compliance-Analyse mit anschließender menschlicher Prüfung der Findings.

Nicht vorgesehen:

• automatisierte Freigabe-/Zulassungsentscheidungen ohne menschliche Aufsicht,
• Entscheidungen über natürliche Personen / Profiling,
• Einsatz als Sicherheitsbauteil eines geregelten Produkts.

4. Genutzte Foundation-Modelle

nori ist provider-agnostisch konfigurierbar. Unterstützt werden u. a.:

Provider	Anbindung	Eigene Model Card
Anthropic (Claude)	Claude Code CLI / API	Model Card des Anbieters (extern)
Google (Gemini)	Gemini CLI / GenAI SDK	Model Card des Anbieters (extern)
OpenAI / Azure OpenAI	OpenAI SDK	Model Card des Anbieters (extern)
Lokale Modelle (Ollama, vLLM, …)	OpenAI-kompatible Endpoints	je Modell

Das je Lauf tatsächlich verwendete Modell wird in run.json (Feld model) festgehalten.

5. Leistungsmerkmale

Die semantische Qualität wird über die nori-regression-Pipeline gemessen:

• Metriken: Precision, Recall, Verdict-Accuracy je Control.
• Verfahren: Lauf gegen einen gepinnten Fixture-Repo, Scoring gegen committete Ground-Truth (agents/ground_truth/), Diff gegen committete Baseline mit Toleranzschwelle und menschlicher Adjudikation.
• Charakter: manuell ausgelöste, semantische Qualitätsschranke (blockiert keine CI); ergänzt durch deterministische Integritäts-Tests.

6. Grenzen und Risiken

• LLM-Inferenz ist nicht deterministisch; Findings können Falsch-Positive/-Negative enthalten – menschliche Prüfung erforderlich.
• Qualität hängt vom gewählten Foundation-Modell und vom bereitgestellten Kontext (Wikis, Control-Definitionen) ab.
• Ergebnisse sind an den geprüften Commit gebunden (gitCommit in run.json).

7. Governance / Nachvollziehbarkeit

• Provenienz je Lauf in run.json (Modell, Git-Commit/-Branch, Zeitstempel, Score, Token/Kosten).
• Findings mit Datei-/Zeilen-Referenz.
• Menschliche Aufsicht und Feedback-Schleife im Dashboard.