Normkontor · FYN Labs · Deutschland & EU

Kontrollierte KI-Arbeit. Nachweisbar.

Regelwerke, unabhängige Prüfpfade und Ausbildung für Teams, die agentische Softwareentwicklung in regulierten Umfeldern verantwortbar einführen wollen.

  • Reuse before create
  • Human Gates bleiben bestehen
  • Claims folgen Evidenz

3A Rulesetöffentlicher Quellenkandidat

RolloutPilot auf Anfrage

AcademyPilot auf Anfrage

Review Runtimein Entwicklung

Ein Agenten-Zugang ist noch kein Betriebsmodell.

01Welche Aufgaben und Daten dürfen in welchen Lauf?

02Wer prüft ein Ergebnis unabhängig vom erzeugenden Agenten?

03Welche Evidenz trägt eine Entscheidung — und wer darf sie treffen?

Offen. Umsetzbar. Getrennt.

Open Source, Pilotleistung und geplante Software werden nicht vermischt. Das macht Prüfung, Beschaffung und Skalierung belastbarer.

Public Source Candidate

01 / Open Ruleset

Normkontor 3A

Technischer Pluginname: 3A COD3X

Aligned. Autonomous. Auditable. Zwei Skills halten Agentenarbeit am ursprünglichen Problem, am kleinsten nativen Owner und an nachweisbarer Verifikation.

Repository prüfen ↗
Pilot auf Anfrage

02 / Einführung

Normkontor Rollout

Ein Team · ein Workflow · sechs Wochen

Scope, Konfiguration, Arbeitsmodell, Training, begleiteter Betrieb und eine belegbare Scale-, Revise- oder Stop-Entscheidung.

Pilotstruktur ansehen ↓
Pilot auf Anfrage

03 / Ausbildung

Normkontor Academy

Executive · Practitioner · Assurance Lead

Praxis für Agenten-Setup, Stage 0.5/0.65, CAO, Eval Gates, Review-Zange, Human Gates und Evidenzführung.

Tracks ansehen ↓
In Entwicklung

04 / Software

Normkontor Review

Geplanter MCP/API-Prüfarm

Customer-controlled Review für materielle Entscheidungen: gefrorener Gegenstand, blinde Modellarme, Datenpolitik und belastbares Evidence Receipt.

Zielarchitektur prüfen ↓

Erst kleiner denken. Dann sauber bauen.

Aligned am ursprünglichen Problem. Autonomous innerhalb echter Autorität. Auditable durch einen kleinen vollständigen Pfad und reale Checks.

01

Need

Muss dieses Verhalten oder Artefakt überhaupt existieren?

02

Reuse

Gibt es bereits einen klaren Owner, der repariert oder erweitert werden kann?

03

Native

Kann Framework, Runtime, Agent, Plattform oder Konfiguration es schon?

04

Available

Reicht Standardbibliothek oder eine bereits installierte Abhängigkeit?

05

Reduce

Löst Löschen, Konfigurieren oder eine gezielte Änderung das Problem?

06

Vet

Schließt ein gepflegtes Upstream die belegte Lücke mit weniger Ownership?

07

Create

Sonst: kleinster vollständiger neuer Pfad, sauber verdrahtet und geprüft.

Wenn Scope, Produktionscode, Owner, Zustand oder Reparaturschleifen wachsen: vor der nächsten Erweiterung stoppen, Meta-Ursache prüfen und den kleineren nativen Owner suchen.

Eine zweite Meinung, die als zweite Meinung belegbar ist.

Der MCP-Endpunkt wäre nur die Tür. Blindheit, Modelltrennung, Datenpolitik, Qualifikation und vollständige Receipts machen daraus erst einen belastbaren Prüfarm.

Geplante Reihenfolge: Agent oder CI, Customer Policy Gateway, zwei blinde Prüfarme, Evidence Receipt und abschließendes Human- und CI-Gate.
01Codex · Agent · IDE · CIfrozen subject + authority boundary
02Customer Policy Gatewayidentity · scope · minimize · scrub · route
ABlind Armqualified family one
BBlind Armqualified family two
03Evidence Receiptidentity · findings · disagreement · gaps
HGHuman & CI Gatedecision remains outside the model

Keine verfügbare Managed Runtime

Pflicht bei klassifizierten materiellen Gates

  • gleicher Hash und gefrorener Gegenstand für beide Arme;
  • zwei zusätzliche blinde, author-independent Reviewer;
  • drei aufgelöste Modellfamilien und Entwickler inklusive Primary;
  • datierte, entscheidungsspezifische Qualifikation;
  • kein stiller Fallback, kein gemitteltes Urteil;
  • Receipt mit Einzelbefunden, Widersprüchen und Restlücken.

Die Open-Source-Doctrine beschreibt diesen Vertrag. Sie provisioniert keine Modelle, führt keine Prüfarme aus und behauptet keinen Assurance-PASS.

Regionalität und Scrubbing werden bewiesen, nicht etikettiert.

Frankfurt als Service-Standort beweist keine Frankfurt-Inferenz. Providerroute, Datenklasse, Fallback, Retention und Zugriff müssen je Modell und Vertrag nachvollziehbar sein.

01

Allowlist

Teams, Repositories, Pfade, Zwecke, Datenklassen, Tools und Aktionen.

02

Minimize

Diff oder Symbolpaket vor unbeschränktem Repository-Kontext.

03

Detect

Secrets, PII, Gesundheits-, Schaden-, Beschäftigten- und Zahlungsdaten.

04

Block or redact

Blockieren, wenn Schwärzung Bedeutung oder Sicherheitsfakten zerstört.

05

Route proof

Provider, Modell, Profil, Region, Retention und Fallback im Receipt.

06

Human control

Keine individuelle Leistungsmessung; Merge und Release bleiben bei Ownern.

Vom sicheren Anwenden zum internen Multiplikator.

Rollenbasierte Praxis statt Teilnahme-Badge. Eine Kompetenzbescheinigung bindet Person, Szenario, Regelwerk, Policy, Rubrik, Datum und Restlücken.

1 Tag

Executive & Governance

Engineering Leadership · Risk · Produkt

Betriebsmodell, Risikoklassen, Human Gates, Claims und Entscheidungshoheit.

2 Tage

Practitioner

Entwickler · Reviewer · Plattformteams

Agenten-Setup, native Tools, 3A Ladder, Tests, Receipts und sichere Eskalation.

5 Tage

Trainer & Assurance Lead

Multiplikatoren · Audit · Enablement

Train-the-Trainer, CAO, Eval Design, blinde Prüfarme und praktische Prüfung.

Sechs Wochen bis zu einer belegbaren Entscheidung.

Kein konzernweiter Big Bang: ein Team, ein Workflow, eine Nachweisfrage und vorab benannte Stop-Kriterien.

01

Rahmen

Team, Workflow, Datenklassen, Nachweisfrage und Stop-Kriterien.

02

Konfiguration

Agent, Repository-Regeln, Berechtigungen, native Tools und Evidenzpfad.

03

Enablement

Rollenbasierte Praxis am freigegebenen Arbeitsablauf.

04

Pilotbetrieb

Begleitete Anwendung mit Ausnahme-, Incident- und Supportlog.

05

Evaluation

Qualität, Arbeitsqualität, Reibung, Risiko, Kosten und offene Evidenz.

06

Entscheidung

Scale, Revise oder Stop plus priorisierter 90-Tage-Plan.

Pilot Charter, Arbeitsmodell, Trainingsevidenz, Risikoregister, Eval-Katalog und 90-Tage-Plan.

Scope besprechen

3A COD3X im Normkontor Marketplace.

Ein Plugin, zwei kanonische Skills, null Runtime. Deaktiviere den alten AAA-Code-Marketplace, bevor du den Nachfolger aktivierst, damit nicht zwei implizite Doctrine-Owner konkurrieren.

Codexcodex plugin marketplace add FYN-Labs/normkontorcodex plugin add 3a-cod3x@normkontor
Claude Codeclaude plugin marketplace add FYN-Labs/normkontorclaude plugin install 3a-cod3x@normkontor
Quellcode und Grenzen prüfen ↗

Was Normkontor bewusst nicht behauptet.

  • keine GDPR-, DORA-, AI-Act-, BaFin- oder Security-Zertifizierung;
  • keine aktuelle customer-hosted oder managed Review Runtime;
  • keine Garantie für Frankfurt-only oder EU-only Inferenz;
  • keine gemessene Produktivitäts- oder Qualitätssteigerung;
  • keinen benannten Kunden, Versicherer oder Produktionsrollout;
  • keine offizielle oder unterstützte OpenAI-, Anthropic- oder Hermes-Integration.

Ist ein Pilot charterfähig?

In einem ersten Gespräch klären wir fünf Punkte: Workflow, Team, Datenklasse, Nachweisfrage und Stop-Kriterium.