Erstgespräch →
Erstgespräch →
In Ihrem Team schreibt KI längst Code — schneller, als Reviews hinterherkommen. Wir legen ein KI-Governance-Framework darüber, das Ihre Regeln zu Tests, Sicherheit und Datenschutz maschinenlesbar festhält und Verstöße im Moment des Schreibens abfängt statt Monate später im Audit. Das Framework heißt Intentron. Hinter ihm stehen drei Unternehmen: PRODOC Digital, FrontEnd IT und die Owlist GmbH als Urheberin.
Der Ablauf ist überall derselbe: Sie sagen der KI „bau mir X", zehn Minuten später läuft Code. Drei Wochen später weiß niemand mehr, warum eine Entscheidung so getroffen wurde. Sie fragen wegen eines Fehlers nach — die KI kennt den Kontext nicht mehr. Eine neue Funktion zerstört eine alte. Und welche Version zuletzt stabil war, ist auch nicht mehr klar.
In einem Wochenendprojekt ist das ärgerlich. In einer regulierten Branche ist es ein Geschäftsrisiko. Denn dort reicht es nicht, dass die Software läuft — sie muss dokumentiert, prüfbar und regelkonform sein. Und das eigentliche Risiko ist seine Unsichtbarkeit: KI liefert schnell etwas, das funktioniert. Ob dabei Ihre Security-Schwellen, Datenschutzregeln und Architekturvorgaben eingehalten wurden, sieht man dem Ergebnis nicht an.
Der Befund kommt nachgelagert — im Security-Review oder im Datenschutz-Audit, wenn produktive Software längst im Einsatz ist. Bis dahin ist im Verborgenen ein Berg aus drei Schulden gewachsen: technische Schuld (das Produkt wird schwer wartbar), Compliance-Schuld (Regeln wurden nie geprüft) und Security-Schuld (Schwachstellen wurden nie gefangen). Das Tempo, das die KI gewinnt, zahlen Sie später mit Zinsen zurück.
In regulierten Unternehmen entscheidet selten eine Person allein. Deshalb beantwortet das Framework die Frage nach dem Nutzen für jede Rolle getrennt — mit einem Mechanismus, nicht mit einem Versprechen.
Jede Änderung läuft durch denselben Lebenszyklus: Absicht, Story, Umsetzung, Prüfung, Merge, Review. Was gestern schiefging, wird im Sprint-Review festgehalten und beim Schneiden der nächsten Story zurückgespielt — das Team wiederholt bekannte Fehler nicht ein zweites Mal.
Nein, denn ohne Spezifikationsdatei kommt der Commit nicht durch. Dazu kommt ein Gate gegen Dokumentations-Drift: Laufen Architektur- und Governance-Dokumente auseinander, blockiert es. Veraltete Doku ist technische Schuld in Textform — hier wird sie messbar statt geduldet.
Die Belege entstehen während der Arbeit, nicht nachträglich auf Zuruf: Prüfberichte je Lauf, dokumentierte Absicht je Änderung, erzwungene Freigaben auf sicherheitssensiblen Pfaden. Ein Audit-Werkzeug rekonstruiert die Kette von der Idee über die Spezifikation bis zum Commit.
Sie behalten das Tempo der KI und senken das Risiko, dass nicht regelkonforme Software erst im Audit auffällt — dann, wenn die Korrektur teuer ist. Die Strenge skaliert mit dem Risiko: Ein Experiment läuft leicht, ein reguliertes Produktivsystem streng. Sie stellen das pro Projekt ein, nicht einmal für alles.
Was das im Alltag kostet, steht eine Sektion weiter unten in der Zeile „Aufwand" — ehrlich, mit dem Preis der Alternativen daneben.
Ihr realer Vergleich ist nicht das eine Framework gegen das andere. Es sind drei Haltungen, die Sie in jedem Entwicklungsbereich antreffen — und eine vierte Option.
| KI ungesteuert | KI verbieten | Code-Reviews allein | KI mit Governance | |
|---|---|---|---|---|
| Tempo | Hoch | Niedrig — Ihr Wettbewerb nutzt sie trotzdem | Hoch, bis das Review zum Engpass wird | Hoch |
| Nachvollziehbarkeit | Keine — die Absicht steht nirgends | Gegeben, aber teuer erkauft | Hängt davon ab, wer wann hinsieht | Spezifikation vor jedem Commit, Audit-Trail zurück zur Absicht |
| Audit-Fähigkeit | Belege werden nachträglich gesucht | Unauffällig, weil wenig entsteht | Reviews sind selten prüfbar dokumentiert | Belege entstehen während der Arbeit |
| Wissensverlust bei Personalabgang | Vollständig — das Warum war nur im Kopf | Unverändert zu heute | Teilweise abgefedert | Absicht, Entscheidung und Prüfergebnis bleiben im Projekt |
| Aufwand | Scheinbar null, die Zinsen fallen später an | Verzicht auf den Produktivitätsgewinn | Wächst mit jedem KI-erzeugten Pull Request | Einmalige Einrichtung, danach laufen die Prüfschritte mit |
„KI verbieten" ist in dieser Tabelle keine Strohpuppe: Es ist eine legitime Entscheidung, solange sie bewusst getroffen und durchgesetzt wird. In der Praxis hält sie selten — Entwicklerinnen und Entwickler nutzen die Werkzeuge dann außerhalb der Sichtweite der IT.
Intentron ist ein KI-Governance-Framework für die Softwareentwicklung. Es ist keine autonome KI, die drauflosbaut, sondern ein geführtes Fließband: Zuerst wird die Absicht festgehalten, dann schreibt die KI den Code, und bevor etwas in Ihren Hauptzweig übernommen wird, laufen automatische Kontrollen zu Sicherheit, Qualität und Datenschutz. Was die Prüfung nicht besteht, kommt nicht durch.
Technisch besteht es aus gekapselten Arbeitsanweisungen für KI-Entwicklungswerkzeuge, die zusammen einen kontrollierten Ablauf erzwingen, und aus einem Satz von Prüf-Gates, die an den Werkzeugen selbst ansetzen. Der steuernde Kern liegt dabei bewusst nicht im Werkzeug, sondern im Projektvertrag: einer Datei, in der Ihre Regeln maschinenlesbar stehen.
Urheberin und Rechteinhaberin ist die OWLIST GmbH (Schweiz). Die Produktseite der Herstellerin ist intentron.ai. PRODOC Digital führt das Framework als Delivery-Partner bei Kunden ein.
Release-Stand v0.42.0 — Stand der Zahlen: 07/2026. Alle drei Angaben sind im Repository nachzählbar; wir nennen sie mit Datum, damit erkennbar bleibt, wann sie zuletzt geprüft wurden.
Was soll erreicht werden und warum? Diese Frage wird beantwortet, bevor irgendjemand Code anfasst. Sie ist der Anker, auf den später jede Zeile zurückzuführen ist.
Aus der Absicht wird eine abgegrenzte Aufgabe mit Umfang, Aufwandsschätzung und Definition of Done. Bekannte Anti-Muster aus früheren Sprints fließen hier automatisch ein.
Jetzt erst schreibt die KI Code — im Rahmen der Spezifikation. Ein Filter greift bereits vor dem Schreiben: Zugangsdaten und unsichere Muster landen gar nicht erst auf der Platte.
Linting, statische Sicherheitsanalyse, Abhängigkeitsprüfung und Testabdeckung laufen automatisch. Ohne verknüpfte Spezifikation blockiert der Commit — ohne bestandene Prüfung ebenso.
In der Continuous Integration laufen dieselben Prüfschritte noch einmal — serverseitig und damit nicht von einem lokalen Rechner aus umgehbar. Erst danach geht etwas in den Hauptzweig.
Zum Abschluss wird gegen die Qualitätsziele geprüft und festgehalten, was gelernt wurde. Diese Lernschleife ist der Grund, warum derselbe Fehler nicht in jedem Sprint neu entsteht.
Es gibt nicht eine große Prüfung am Ende, sondern mehrere Kontrollen entlang des Weges. Fällt eine aus, greift die nächste. Entscheidend ist, dass die letzte nicht auf dem Laptop läuft.
Ein Filter prüft jeden Schreibvorgang der KI, bevor er ausgeführt wird, und fängt Passwörter, Token und bekannte unsichere Muster ab. Verhindert den Fall, dass ein Schlüssel erst im Repository auffällt — und dann in der Historie steht.
Linting, statische Sicherheitsanalyse und die Prüfung auf erfundene oder verwundbare Abhängigkeiten laufen beim Commit. Verhindert, dass halluzinierte Paketnamen und bekannte Schwachstellen überhaupt in einen Pull Request geraten.
Dieselben Prüfschritte laufen serverseitig noch einmal, als verpflichtende Statusprüfung vor dem Merge. Verhindert den einen Fall, der lokale Prüfschritte wertlos macht: dass jemand sie unter Zeitdruck übergeht.
Für Unternehmen unter MDR, DORA, MaRisk oder KRITIS ist die Frage nach dem Betriebsmodell keine technische Vorliebe, sondern Teil der Compliance-Akte.
Das Framework ist forge-flexibel: Es läuft auf GitHub ebenso wie auf selbst gehosteten Gitea- oder Forgejo-Instanzen. Code, Aufgabenverwaltung und CI können damit vollständig in Ihrem Rechenzentrum bleiben. Lokale Sprachmodelle sind vorgesehen — es besteht kein Zwang zu einem US-Anbieter. Datensouveränität heißt hier nicht nur, wo die Daten liegen, sondern welchem Recht sie unterliegen.
Ein versionierter Kontrollkatalog zu DSGVO, BDSG und nDSG wird deterministisch abgearbeitet und liefert je Punkt ein Ergebnis. Berührt eine Änderung personenbezogene Pfade, verlangt das Framework eine Datenschutz-Freigabe, bevor sie durchgeht.
Ein Katalog zum EU AI Act ist als Erweiterung verfügbar. Unabhängig davon zahlt der revisionssichere Audit-Trail direkt auf die Dokumentationspflichten ein: Zu jeder Änderung liegen Absicht, Prüfergebnis und Freigabe unveränderbar an einem definierten Ort — statt in Chat-Verläufen.
Jedes Projekt trägt eine Vertraulichkeitsstufe. Sie lenkt, welche Modelle und Endpunkte für welche Daten zulässig sind. Ab der Stufe „vertraulich" ist vorgesehen, dass die Durchsetzung an der Plattform hängt und nicht am Wohlverhalten des einzelnen Arbeitsplatzes.
Wir empfehlen nichts, was wir nicht selbst betreiben. Die Seite, die Sie gerade lesen, wird unter demselben Verfahren gebaut — nachprüfbar an konkreten Artefakten im Repository:
Der zweite, wichtigere Beleg ist eine Auslassung: Dieses Projekt läuft in der mittleren Governance-Stufe, aber mit dokumentierten Ausnahmen. Vier Gates, die bei einer statischen Website ohne Laufzeitlogik keinen Erkenntnisgewinn bringen, sind ausdrücklich abgeschaltet — mit Begründung und mit dem Hinweis, wann sie nachzurüsten wären.
Genau das ist der Punkt, an dem sich zeigt, ob ein Regelwerk taugt: Es muss sich am Risiko ausrichten lassen, ohne dass jemand heimlich Prüfschritte umgeht. Wir führen das hier vor, statt es zu behaupten.
Die Strenge ist keine Einbahnstraße. Sie starten leicht und ziehen nach, wenn aus dem Prototyp ein Produkt wird.
| lite | standard | heavy | |
|---|---|---|---|
| Wofür gedacht | Wegwerf-Skripte, Lernprojekte, folgenlose Experimente | Kundenarbeit, kleine Produktivservices, seriöse Solo-Projekte | Regulierte, umsatzkritische oder langlebige Systeme |
| Immer aktiv | Projektvertrag, Spezifikationspflicht, Basis-Linting | zusätzlich Security-Gates, sensible Pfade, Lernschleife | zusätzlich Testabdeckung, Branch-Schutz, verpflichtendes Review |
| Nachweis-Tiefe | Absicht dokumentiert | Prüfberichte je Lauf | durchgängiger Audit-Trail mit Freigaben |
| Typischer Auslöser | Kein Schutzbedarf, keine Folgen | Externe Auftraggeber oder mehrere Entwickler | Personenbezogene Daten, Zahlungs- oder Authentisierungslogik, Regulierung |
Treffen mehrere Auslöser gleichzeitig zu — reguliert und personenbezogen und umsatzkritisch —, ist heavy die richtige Antwort. Diese Zuordnung ist Teil des Governance-Assessments.
Intentron ist kein Open-Source-Projekt zum Ausprobieren. Das Repository ist privat, Rechteinhaberin ist die OWLIST GmbH. Wer es nutzen will, bekommt den Zugang über ein Partner- und Pilotmodell.
Wir schreiben das hier hin, statt es zu umschiffen — sonst suchen Sie eine Viertelstunde nach einem Download-Link, den es nicht gibt. Der übliche Weg führt über ein Governance-Assessment zu einem abgegrenzten Pilotprojekt; erst danach entscheiden Sie über eine dauerhafte Nutzung.
Intentron wird gemeinsam vermarktet. Wer welchen Teil verantwortet, sollen Sie vor dem ersten Gespräch wissen — nicht danach.
Goslar, Deutschland. Führt das Framework bei Ihnen ein, übersetzt Ihre regulatorischen Anforderungen in Gate-Konfigurationen und schult Ihr Team. Ansprechpartner ist Stefan Weimar, TÜV-zertifizierter KI-Berater.
Böblingen, Deutschland. Bringt Entwicklungs- und Betriebsleistung mit und betreibt die Infrastruktur, wenn Sie das Framework nicht selbst hosten wollen. frontend-it.de
Schweiz. Entwickelt das Framework und hält die Rechte an INTENTRON. Produktseite der Herstellerin: intentron.ai · owlist.ch
Der letzte Punkt ist der wichtigste: Das Framework macht menschliche Urteile nachweisbar — es ersetzt sie nicht. Wo niemand entscheidet, hilft auch kein Gate.
Der Aufwand entsteht einmalig bei der Einrichtung: Ihre Regeln zu Tests, Sicherheit und Datenschutz werden in einen maschinenlesbaren Projektvertrag geschrieben. Danach laufen die Prüfschritte im Hintergrund mit und melden sich nur, wenn sie etwas finden. Die Strenge lässt sich pro Projekt einstellen — ein Wegwerf-Prototyp läuft in der leichtesten Stufe, ein reguliertes Produktivsystem in der schärfsten.
Ja — aber eine Spezifikation ist hier kein Lastenheft, sondern eine kurze Datei mit Absicht, Umfang und Definition of Done. Sie entsteht im selben Arbeitsschritt, in dem die Aufgabe ohnehin beschrieben wird. Der Gegenwert: Sechs Monate später steht dort, warum eine Entscheidung so getroffen wurde. Genau diese Antwort fehlt sonst im Audit und bei jeder Übergabe.
Das ist eine berechtigte Sorge und der häufigste Grund, warum Regelwerke scheitern. Zwei Dinge helfen: Erstens ist die Strenge einstellbar — Sie beginnen in der Stufe, die zum Risiko passt, und ziehen erst nach, wenn aus dem Prototyp ein Produkt wird. Zweitens werden dokumentierte Ausnahmen unterstützt: Gates, die für Ihr Projekt keinen Sinn ergeben, dürfen mit Begründung abgeschaltet werden. Wir machen das auf dieser Website selbst so.
Umgekehrt: Sie gewinnen sie zurück. Ohne Rahmen liefert die KI schnell etwas, das läuft — ob dabei Ihre Regeln eingehalten wurden, sieht man dem Ergebnis nicht an. Mit Rahmen steht die Absicht vor dem ersten Commit fest, jede Änderung durchläuft dieselben Prüfschritte, und ein Audit-Trail führt von jeder Zeile zurück zur ursprünglichen Absicht. Die fachlichen Urteile bleiben bei Ihren Leuten — das Framework macht ihre Arbeit nachweisbar, es nimmt sie ihnen nicht ab.
Ja. Die Entscheidung, die Sie treffen, ist keine technische: Wie streng sollen die Prüfschritte greifen, welche Pfade brauchen eine menschliche Freigabe, wer nimmt Sicherheit und Datenschutz ab? Diese Stellschrauben sind in Geschäftssprache beschrieben. Zu jeder Rolle — Geschäftsführung, CTO, CIO, CISO — existiert eine eigene Lesebrille von unter zehn Minuten Länge, die genau deren Fragen beantwortet.
Nein, und das ist wichtig. Das Framework ersetzt weder einen externen Penetrationstest noch eine juristische Bewertung Ihres konkreten Falls, und es garantiert keine Fehlerfreiheit. Es sorgt dafür, dass Regelverstöße früh gefangen werden und dass die Belege für eine Prüfung während der Arbeit entstehen statt nachträglich. Der Unterschied ist der zwischen „wir hoffen, es passt" und „wir können zeigen, dass es passt".
Nein. Intentron ist kein öffentliches Open-Source-Projekt — das Repository ist privat, Rechteinhaberin ist die OWLIST GmbH. Der Zugang läuft über ein Partner- und Pilotmodell. Der übliche Weg ist ein Governance-Assessment, aus dem ein abgegrenzter Pilot hervorgeht; erst danach entscheiden Sie über eine dauerhafte Nutzung.
Nein. Der steuernde Kern liegt im Projektvertrag, nicht im Werkzeug: Regeln, Spezifikationen, Gates und Nachweise bleiben bestehen, wenn Sie die Entwicklungsumgebung wechseln. Auf der Infrastrukturseite gilt dasselbe — das Framework läuft auf GitHub ebenso wie auf selbst gehosteten Gitea- oder Forgejo-Instanzen, und lokale Sprachmodelle sind vorgesehen.
Zwei Tage, ab 5.000 € zzgl. USt. Sie bekommen eine Gate-Landkarte Ihres bestehenden Repositorys, eine begründete Reifegrad-Empfehlung, eine Maßnahmen-Roadmap und einen Vorschlag für den ersten Pilot-Scope. Voraussetzung ist Lesezugriff auf ein Repository — mehr brauchen wir nicht.
Bevor ein Rahmen greift, muss das Team die Werkzeuge beherrschen. Im Entwickler-Workshop baut Ihr Team in ein bis drei Tagen einen funktionsfähigen Prototypen — mit Ihrem Code, in Ihrer Infrastruktur.
Mehr zu unseren Workshops →Wenn die Daten das Haus nicht verlassen dürfen: Beratung, Architektur und Implementierung von KI-Systemen, die vollständig auf Ihrer Hardware laufen — ohne Cloud, ohne laufende API-Kosten.
Mehr zu lokalen KI-Lösungen →