
Intentron
Ihre Geräte verkaufen sich nur zusammen mit Ihrer Software. Intentron sorgt dafür, dass diese Software weiterentwickelt werden kann, auch wenn eine KI daran schreibt und auch wenn die Leute wechseln, die sie entwickelt haben und in- und auswendig kennen.
Intentron ist ein Regelwerk für die Softwareentwicklung mit KI, im Englischen ein Framework. Es legt drei Dinge fest: was geklärt sein muss, bevor programmiert wird, was während des Programmierens automatisch geprüft wird, und was am Ende schriftlich vorliegt.
Die KI arbeitet weiterhin schnell. Sie arbeitet nur nicht mehr unkontrolliert: Was sie liefert, wird automatisch geprüft, bevor es weitergeht.
Technisch besteht Intentron aus festen Arbeitsabläufen für KI-Entwicklungswerkzeuge und aus automatischen Prüfungen, die an diesen Werkzeugen ansetzen. Der steuernde Kern liegt aber nicht im Werkzeug, sondern in einer Datei im Projekt, die wir den Projektvertrag nennen. Darin stehen die Regeln Ihres Unternehmens in einer Form, die eine Maschine lesen kann.
Diese eine Datei wird von drei Seiten gelesen: von Ihren Entwicklern, von der KI und von den automatischen Prüfungen. Deshalb kann keine Lücke entstehen zwischen dem, was gemeint war, dem, was gebaut wurde, und dem, was tatsächlich kontrolliert wird. Alle drei beziehen sich auf dieselbe Quelle.
Was Intentron ausdrücklich nicht ist: ein selbstständig arbeitendes Programm, dem man eine Anforderung übergibt und das irgendwann fertige Software zurückliefert. Es ist ein Weg in festen Schritten, und nach jedem Schritt wird geprüft, bevor der nächste beginnt. Gesteuert wird dieser Weg von Ihren Leuten.
Warum es einen solchen Rahmen überhaupt braucht, zeigt der Blick darauf, wie KI gerade in Entwicklungsabteilungen einzieht.

Software mit KI erstellen dauert heute Minuten. Vibe Coding heißt: Man beschreibt einer KI, was man will, und lässt sie loslegen. Nach wenigen Minuten läuft etwas. Für einen Versuch am Wochenende ist das großartig. In einem Produkt, das Sie zehn Jahre ausliefern und warten müssen, verschiebt es die Kosten nur nach hinten.
Das Heikle daran ist nicht, dass Fehler passieren. Das Heikle ist, dass man sie nicht sieht. Was die KI abliefert, läuft und sieht ordentlich aus. Ob dabei Ihre Sicherheitsregeln eingehalten wurden, ob mit Kundendaten richtig umgegangen wird, ob ein fertiger Baustein aus fremder Quelle, den die KI eingebaut hat, überhaupt geprüft wurde: Dem Ergebnis sieht man das nicht an.
Deshalb kommt die Rechnung später. Sie kommt in der Sicherheitsprüfung, im Datenschutz-Audit oder an dem Tag, an dem jemand fragt, warum eine Sache so gebaut wurde, und niemand mehr die Antwort weiß.
Der Ausweg verlangt kein geringeres Tempo. Er verlangt einen anderen Zeitpunkt für die Prüfung. Intentron nennt das den Schritt vom Vibe Coding zum Vibe Engineering: Die Regeln stehen vorher fest und werden im Moment des Schreibens durchgesetzt, statt hinterher geprüft zu werden.
Konkret heißt das dreierlei. Erstens gibt es zu jeder Änderung eine kurze Aufgabenbeschreibung mit einem Ziel und einer Bedingung, an der sich die Abnahme messen lässt. Fehlt diese Beschreibung, wird die Änderung nicht übernommen. Zweitens laufen die Prüfungen auf Sicherheit, Datenschutz und Codequalität automatisch mit, an mehreren Stellen hintereinander. Drittens bleibt jede Änderung mit der Absicht verbunden, aus der sie entstanden ist, sodass sich die Kette später zurückverfolgen lässt.
Die zweite Hälfte des Problems ist älter als die KI: Das Wissen über Ihre Software steckt in wenigen Köpfen. Davon handelt der Abschnitt über Ihren bestehenden Code weiter unten.
Sechs Stationen, die wir in fast jedem Gespräch mit Herstellern wiederfinden. Vielleicht erkennen Sie Ihr Unternehmen an einer davon wieder.
01
Ein kleines Entwicklungsteam, eingespielt über Jahre. Wie hier gearbeitet wird, steht nirgends geschrieben, es steckt in den Köpfen. Das funktioniert gut, solange die Köpfe dieselben bleiben.
02
Die KI-Werkzeuge zum Programmieren sind da, und sie sind gut. Die ersten Entwickler nutzen sie, ob das offiziell erlaubt ist oder nicht. Die Frage ist längst nicht mehr, ob bei Ihnen eine KI programmiert. Die Frage ist, unter welchen Bedingungen sie das tut.
03
Der eine ist Tempo ohne Aufsicht: Es entsteht mehr Code, als irgendjemand noch durchsehen kann. Der andere ist ein Verbot, KI im Haus einzusetzen. Es verschenkt den Vorteil und wird in der Praxis ohnehin umgangen, weil die Werkzeuge auf jedem privaten Rechner verfügbar sind.
04
Der Ausweg liegt vor dem Programmieren, nicht danach. Wer aufschreibt, was herauskommen soll und woran man das erkennt, gibt der KI etwas, woran sie sich messen lassen muss.
05
Was hilft, ist ein Geländer: Regeln, die eine Maschine lesen und durchsetzen kann. Sie fallen nicht auf, solange alles läuft. Sie melden sich, wenn etwas nicht stimmt, und sagen dann auch, was.
06
Tippen ist nicht mehr der Engpass. Der Engpass ist das Verstehen: das Richtige bauen, den Zusammenhang festhalten, die Entscheidung begründen. Genau dorthin verschiebt sich die Arbeit Ihrer Leute.
Die vierte Station, das Aufschreiben der Absicht, ist der Kern des Frameworks. Sie verdient einen eigenen Abschnitt.
Bevor jemand baut, wird aufgeschrieben, was dabei herauskommen soll, woran man erkennt, dass es erreicht ist, und was ausdrücklich nicht dazugehört. Erst danach wird programmiert.
Das klingt selbstverständlich und ist trotzdem der Fehler, der in KI-Projekten am meisten kostet. Eine KI baut in kurzer Zeit das Falsche, wenn vorher niemand das Ziel festgehalten hat. Und weil sie schnell ist, fällt es spät auf.
Tobias Schmidt, von dem das Framework stammt, erklärt es mit einem Bild. Sie stehen an einem Fluss und wollen ans andere Ufer. Werfen Sie ein Seil um den Baum am anderen Ufer und hangeln Sie sich daran hinüber, bekommen Sie nasse Füße, kommen aber genau dort an, wo Sie hinwollten. Steigen Sie ohne Seil ins Wasser, nimmt die Strömung Sie mit, und Sie kommen irgendwo an. Das Seil ist die festgehaltene Absicht.
Diese festgehaltene Absicht heißt im Framework der Intent. Er ist keine Anforderungsliste, sondern eine knappe Beschreibung des angestrebten Ergebnisses aus Sicht dessen, der es nutzt, zusammen mit den Bedingungen, unter denen es als erreicht gilt. Aus dem Intent entsteht anschließend die Aufgabenbeschreibung, aus der Aufgabenbeschreibung der Code, und die Verbindung zwischen den dreien bleibt bestehen.
Woran man einen brauchbaren Intent erkennt, lässt sich in einem Satz sagen: Ein Entwickler muss ihm selbst entnehmen können, ob seine Arbeit auf das Ziel einzahlt. Kann er das nicht, ist der Intent zu vage, und das Framework schickt ihn zurück.
Die Wirkung aus Sicht des Nutzers, keine Lösungsbeschreibung.
Bedingungen, die sich prüfen lassen, nicht Absichtserklärungen.
Die ausdrückliche Abgrenzung. Sie verhindert, dass aus einer klaren Aufgabe unterwegs drei unklare werden.
Wie es sich anfühlt, einen solchen Auftrag zu schreiben, können Sie ohne Projekt und ohne Termin ausprobieren.
Der gut formulierte Auftrag ist die Stelle, an der bei uns alles hängt. Genau die geben wir heraus, kostenlos und ohne weitere Bedingung: ein geführtes Gespräch, das aus einem Vorhaben eine klare und prüfbare Zielbeschreibung macht.
Sie erzählen in Ihren Worten, was Sie vorhaben. Am Ende steht ein Text, mit dem ein Entwickler oder eine KI tatsächlich arbeiten kann.
Der Intent-Chat-Skill läuft in Claude, braucht keine Installation in Ihrem Projekt und funktioniert unabhängig vom übrigen Framework. Er fragt nach, schlägt Formulierungen vor und prüft das Ergebnis am Schluss gegen eine feste Liste typischer Schwächen. Was er ausgibt, hat dasselbe Format wie der entsprechende Schritt im vollständigen Framework, ist also anschlussfähig, falls Sie später weitermachen. Entschieden wird nichts über Ihren Kopf hinweg: Der Skill schlägt vor, Sie legen fest.
Die Anforderung läuft über die Seite unseres Partners PRODOC Digital. Den Link erhalten Sie von dort per E-Mail.

In jedem Unternehmen gibt es Regeln dafür, wie Software gebaut wird: was getestet sein muss, was mit Kundendaten passiert, was niemand allein entscheiden darf. Meistens stehen sie in einem Dokument, das alle einmal gelesen haben. Ob sie eingehalten wurden, merkt man, wenn etwas passiert ist.
Intentron schreibt diese Regeln stattdessen in eine Datei, die das Entwicklungssystem selbst liest und durchsetzt. Wer dagegen verstößt, kommt nicht weiter. Nicht, weil jemand aufpasst, sondern weil die Änderung technisch nicht übernommen wird.
Die Prüfungen sitzen an vier Stellen hintereinander, und was durch die eine rutscht, fängt die nächste.
01
Ein Wächter prüft jeden Schreibvorgang der KI, bevor er ausgeführt wird, und fängt Passwörter, Zugangsschlüssel und bekannte unsichere Muster ab. Damit landet ein versehentlich hineingeschriebenes Geheimnis gar nicht erst in der Versionsgeschichte, aus der es später kaum zu entfernen ist.
02
Bevor eine Änderung festgeschrieben wird, laufen eine Stilprüfung, eine Sicherheitsanalyse des Codes und eine Kontrolle der eingebauten Bausteine anderer Anbieter. Geprüft wird dabei auf bekannte Schwachstellen und auf Bausteine, die es gar nicht gibt und deren Namen die KI erfunden hat. Wird etwas Ernstes gefunden, geht es nicht weiter.
03
Dieselben Prüfungen laufen ein zweites Mal in frischer Umgebung, als verpflichtende Bedingung, bevor eine Änderung in die Fassung übernommen wird, die später ausgeliefert wird. Das ist die Schicht, die sich auch unter Zeitdruck nicht überspringen lässt.
04
Änderungen an Bereichen, die Sie vorher festlegen, halten an, bis jemand ausdrücklich freigibt. Typisch sind Anmeldung, Zahlungsvorgänge und alles, was personenbezogene Daten berührt. Welche Bereiche das sind, bestimmen Sie, nicht das Framework.
Eine fünfte Sicherung betrifft die Prüfungen selbst. Schlägt eine an, ist die bequeme Abkürzung, nicht den Fehler zu beheben, sondern die Prüfung leiser zu stellen. Das erkennt das System und meldet es. Abschalten darf nur ein Mensch, mit Begründung und Namen darunter.
Nicht jedes Vorhaben braucht dieselbe Schärfe. Es gibt drei Stufen: eine leichte für Versuche ohne Folgen, eine mittlere für Kundenarbeit, eine strenge für regulierte oder umsatzkritische Systeme. Sie fangen klein an und ziehen nach, wenn aus dem Versuch ein Produkt wird, ohne das Projekt neu aufzusetzen. Je weicher die Regeln, desto höher Ihr Risiko, und wie viel Risiko Sie tragen wollen, ist Ihre Entscheidung und nicht die des Frameworks.
Damit ist geklärt, wie geprüft wird. Der nächste Abschnitt zeigt, in welcher Reihenfolge gearbeitet wird.
Jede Aufgabe nimmt bei Intentron denselben Weg. Der Grund dafür ist kein Ordnungssinn, sondern eine Beobachtung: Ein System, das eine Anforderung in einem Zug in fertige Software verwandelt, liefert schlechtere Qualität als ein Weg, der Schritt für Schritt geprüft wird. Deshalb sieben Stationen statt einer großen Maschine.
1
Was soll für den Nutzer herauskommen, und warum ist das wichtig? Diese Frage wird beantwortet, bevor jemand über Lösungen spricht. Sie ist der Anker, auf den später jede Zeile zurückführt.
2
Aus dem Ziel wird eine abgegrenzte Aufgabe mit Abnahmebedingungen und einer knappen Beschreibung dessen, was zu bauen ist. Was in früheren Abschnitten schiefging, fließt hier automatisch wieder ein.
3
Was geht zuerst, was hängt woran? Aus einer Liste von Aufgaben wird ein Arbeitsplan.
4
Jetzt erst wird Software mit KI erstellt, im Rahmen der Aufgabenbeschreibung. Immer nach demselben Muster: bauen, testen, prüfen, bei Fehlern die Ursache beheben statt das Symptom, erneut prüfen. Erst wenn alle Prüfungen grün sind, gilt der Schritt als fertig.
5
In Abständen ein Schritt zurück: Passt das Gebaute noch zur geplanten Gesamtstruktur, und wo sammeln sich Abkürzungen an, die später teuer werden?
6
Am Ende eines Abschnitts wird festgehalten, was gelernt wurde. Und, das ist der eigentliche Punkt, vor der nächsten Aufgabe wieder gelesen. Derselbe Fehler passiert kein zweites Mal.
7
Die Belege werden zusammengetragen: Was wurde erreicht, welche Zahlen zeigen es, wurde die ursprüngliche Absicht erfüllt? Daraus entsteht ein kurzes Briefing für alle Beteiligten. Vorgetragen wird es von einem Menschen.
Die KI durchläuft diese Strecke weitgehend selbstständig, bis kurz vor dem Ziel. Der letzte, nicht umkehrbare Schritt bleibt beim Menschen: die Übernahme in die Fassung, die bei Ihren Kunden läuft, das Austauschen von Zugangsschlüsseln, das Ausrollen an echte Nutzer.
Das ist keine technische Grenze, man könnte es automatisieren. Es ist eine Abwägung. Wo ein Fehler billig und rückgängig zu machen ist, darf die KI allein arbeiten. Wo er teuer und endgültig ist, entscheidet ein Mensch. Kein Regelwerk ist lückenlos, und diese Restwahrscheinlichkeit trägt an den teuren Stellen niemand blind.
Aus diesem Aufbau ergeben sich sechs Eigenschaften, die im Alltag den Unterschied machen.
Sechs Dinge, die den Unterschied machen, sobald aus dem ersten Projekt normale Arbeit geworden ist. Unter jedem Punkt steht klein der Fachbegriff dazu, falls Ihre IT ihn braucht.
Zu jeder Änderung ist festgehalten, welche Absicht dahinterstand. Ein halbes Jahr später steht dort, warum eine Entscheidung so getroffen wurde. Genau diese Antwort fehlt sonst bei jeder Übergabe und bei jeder Fehlersuche.
Fachlich: dokumentierter Intent je Änderung
Sicherheit und Datenschutz werden nicht am Ende geprüft, sondern laufen von der ersten Zeile an mit. Ein Problem fällt auf, solange es klein ist und sich mit wenigen Handgriffen beheben lässt.
Fachlich: Quality Gates in vier Schichten
Von der einzelnen Zeile zurück zur Aufgabe und von dort zur ursprünglichen Absicht: Die Kette bleibt lückenlos. Die Belege entstehen während der Arbeit, nicht nachträglich auf Zuruf, wenn eine Prüfung ansteht.
Fachlich: durchgängiger Audit-Trail
Code, Aufgabenverwaltung und Prüfläufe können vollständig auf Ihren eigenen Servern laufen. Als KI lässt sich auch ein Modell einsetzen, das bei Ihnen betrieben wird, sodass keine Inhalte an einen Cloud-Dienst gehen.
Fachlich: self-hosted, lokale Modelle möglich
Ihre Regeln liegen im Projekt selbst und nicht in dem Programm, mit dem gearbeitet wird. Wechseln Sie den Anbieter oder die Entwicklungsumgebung, bleiben Vorgaben, Aufgabenbeschreibungen und Nachweise bestehen. Sie tauschen ein Werkzeug, nicht Ihre Arbeitsweise.
Fachlich: Werkzeugneutralität
Die fachlichen Urteile bleiben bei Menschen. Das Framework macht ihre Arbeit nachweisbar, es nimmt sie ihnen nicht ab. Wo bei Ihnen niemand entscheidet, hilft auch keine Automatik.
Fachlich: Human in the Loop
Als KI-Werkzeug lassen sich Claude Code, Codex oder Cursor einsetzen. Als Plattform für den Code GitHub, Gitea oder Forgejo. Für die Aufgabenverwaltung Linear, Jira, GitHub Issues oder Microsoft Planner. Welches KI-Modell hinter diesen Werkzeugen arbeitet, entscheiden Sie ebenfalls, ausdrücklich auch ein Modell, das bei Ihnen selbst betrieben wird.
Die Wahl steht im Projektvertrag und lässt sich wechseln, ohne dass Regeln, Aufgabenbeschreibungen oder Nachweise verloren gehen. Dazu gehört eine bewusste Sparsamkeit: Bringt ein Anbieter eine Fähigkeit inzwischen selbst mit, baut das Framework sie nicht nach, sondern nutzt die eingebaute Funktion.
Diese sechs Punkte gelten auch dann, wenn Sie nicht bei null anfangen. Und das ist der Normalfall.

In vielen Unternehmen gibt es eine Software, die seit Jahrzehnten läuft, Geld verdient und ohne die sich kein Gerät verkaufen lässt. Gepflegt wird sie von ein oder zwei Leuten. Aufgeschrieben ist wenig. Wenn diese Leute in Rente gehen, geht das Wichtigste mit.
Das ist kein Einzelfall, sondern der Normalfall einer ganzen Branche. Für ihn gibt es einen eigenen Einstieg, und er ist deutlich kleiner als eine Umstellung der ganzen Entwicklung.
Legacy Code ist Software, die im Einsatz ist, aber ohne die Menschen, die sie geschrieben haben, kaum noch veränderbar. Nicht, weil sie schlecht wäre. Sondern weil das Wissen darüber im Kopf steckt und nicht im Projekt.
Das Bestands-Onboarding liest Ihre vorhandene Software ein. Parallel dazu spricht der Entwickler, der sie kennt, seine Erklärungen dazu: warum etwas so gebaut wurde, welche Sonderfälle es gibt, wo die Fallstricke liegen. Beides wird zusammengeführt.
Heraus kommt zweierlei. Eine Dokumentation, mit der ein Nachfolger wirklich arbeiten kann. Und, das ist der eigentliche Hebel, ein Bestand, an den sich anknüpfen lässt: Die KI weiß danach, welche Bausteine in Ihrer Software schon vorhanden sind, benutzt diese, statt Vorhandenes neu zu erfinden, und schreibt im gleichen Stil weiter wie Ihre Entwickler.
Die Reihenfolge ist damit klar. Vor der KI-gestützten Entwicklung kommt die KI-gestützte Dokumentation.
Das Einlesen erzeugt eine Dokumentation in zwei Ausprägungen: lesbar für Menschen und auswertbar für Maschinen, mit den besprochenen Sonderfällen an Ort und Stelle. Danach lässt sich das Framework in dasselbe Projekt nachrüsten, ohne dass es neu aufgesetzt werden muss. Der Nachrüstweg ergänzt fehlende Regeln, Prüfungen und Dokumente behutsam, lässt vorhandenen Code unangetastet, fasst keine Zugangsdaten an, und Sie können vorher ansehen, was er tun würde.
Der Einstieg ist bewusst klein gehalten. Es braucht Ihre vorhandene Software und den Entwickler, der sie kennt. Danach haben Sie eine Entscheidungsgrundlage statt einer Vermutung.
Wie ein Einstieg praktisch abläuft, steht im nächsten Abschnitt.
Intentron ist nichts, was Sie herunterladen und allein ausprobieren. Das Framework kommt zusammen mit den Leuten, die es einführen, weil die Arbeit zur Hälfte darin besteht, die Regeln Ihres Unternehmens überhaupt erst aufzuschreiben.
Der übliche Weg beginnt mit einem Gespräch über Ihr Vorhaben und einem abgegrenzten ersten Projekt. Erst danach entscheiden Sie, ob Sie dabei bleiben. Wir sagen von uns aus, wenn wir nicht passen: Ein Versuch ohne Folgen braucht diesen Rahmen nicht, und wo bei Ihnen niemand Sicherheit und Datenschutz fachlich abnimmt, hilft auch kein Framework.
Intentron wird gemeinsam vermarktet. Die Zuständigkeiten sind klar geschnitten, damit Sie wissen, mit wem Sie es wofür zu tun haben.
Entwickelt das Framework, hält die Rechte an Intentron und übernimmt Erweiterungen, die nur für Ihr Unternehmen gelten.
Führt das Framework bei Ihnen ein, übersetzt Ihre Anforderungen in Regeln und schult Ihr Team: KI-Beratung für Unternehmen.
Bringt Entwicklungs- und Betriebsleistung mit und stellt die Server im eigenen Rechenzentrum, wenn Sie sie nicht selbst betreiben wollen.
Das Framework ist in laufenden Kundenprojekten entstanden, und das Team dahinter arbeitet selbst nach den Regeln, die es Ihnen vorschlägt.

Tobias Schmidt hat das Intentron-Framework entwickelt, ausgehend von der Frage, wie er als CIO ein KI-gestütztes Entwicklungsteam führen würde.
owlist.ch
Carl-Christian Anders verantwortet bei Owlist die Finanzen, Unternehmensstruktur, Recht und Compliance.
owlist.ch
Stefan Weimar bringt KI dorthin, wo die Daten bleiben müssen: ins Unternehmen selbst.
prodoc-digital.com
Axel Beckert deckt die technische Kette ab, von Planung und Entwicklung bis zum Betrieb im eigenen Rechenzentrum.
frontend-it.deDie Expertinnen und Experten des Delivery-Teams arbeiten in Ihrem Projekt mit, jeweils mit ihrem eigenen Schwerpunkt. Beauftragt werden sie über das Kernteam.

Frank Petermann arbeitet dort, wo IT und Fachbereich aufeinandertreffen: Er versteht beide Seiten und übersetzt zwischen ihnen.
frankpetermann.com
Katrin Friedel sorgt dafür, dass die Veränderungen durch eine KI-Einführung bei den Menschen ankommen, die sie im Alltag tragen.
katrinfriedel.com
Peter Raehse schließt die Lücke zwischen Produktidee und produktionsreifer KI-Lösung: Er macht aus einem Intent eine produktive Anwendung.
raehse.com
Thomas Völker bringt KI als laufendes System in inhabergeführte Betriebe, vom ersten Gespräch bis zur Strecke, die im Alltag ohne zusätzliche Person läuft.
voelker.ai
Carsten Wittmann macht aus KI-Experimenten belastbare Unternehmenspraxis, mit Governance und Datenschutz, die im Alltag funktionieren und im Audit standhalten.
tumaki.deNein. Das Framework ist nicht öffentlich verfügbar, Rechteinhaberin ist die Owlist GmbH. Wenn Sie das Framework einsetzen wollen, schreiben Sie an info@owlist.ch. Wir melden uns und klären, ob Ihr Vorhaben dafür passt. Frei verfügbar ist der Intent-Chat-Skill weiter oben auf dieser Seite.
Ja, denn die Entscheidungen, die Sie treffen, sind keine technischen. Wie streng soll geprüft werden, welche Bereiche brauchen eine ausdrückliche Freigabe, wer nimmt bei Ihnen Sicherheit und Datenschutz fachlich ab? Das sind Fragen nach Risiko und Zuständigkeit. Die technische Umsetzung liegt danach bei Ihren Entwicklern.
Ja, und das ist der häufigste Einstieg. Das Framework zieht auch nachträglich in gewachsene Projekte ein. Es ergänzt fehlende Regeln, Prüfungen und Dokumente behutsam, lässt vorhandenen Code in Ruhe und fasst keine Zugangsdaten an. Bevor es etwas verändert, können Sie sich anzeigen lassen, was es verändern würde.
Der Aufwand fällt bei der Einrichtung an. Danach laufen die Prüfungen im Hintergrund mit und melden sich nur, wenn sie etwas finden. Die Strenge stellen Sie pro Projekt ein. Die eigentliche Zeit verliert man an dem, was ohne Prüfung erst drei Wochen später auffällt.
Darauf gibt es keine dauerhafte Antwort, und genau deshalb legt Intentron sich nicht fest. Welche KI fürs Coding gerade vorn liegt, ändert sich im Halbjahrestakt, und die Werkzeuge unterscheiden sich in ihren Stärken. Was bleibt, ist der Rahmen: Solange Absicht, Regeln und Nachweise im Projekt liegen und nicht im Werkzeug, können Sie das Modell wechseln, ohne Ihre Arbeitsweise zu wechseln.
Human in the Loop heißt, dass die KI nicht durchläuft, sondern an festgelegten Stellen anhält und auf eine menschliche Entscheidung wartet. Bei Intentron sind das die Schritte, die sich nicht zurücknehmen lassen: die Übernahme in die ausgelieferte Fassung, das Austauschen von Zugangsschlüsseln, das Ausrollen an echte Nutzer. Welche weiteren Bereiche eine Freigabe brauchen, legen Sie selbst fest.
Ja. Code, Aufgabenverwaltung und Prüfläufe können vollständig auf Ihren eigenen Servern laufen. Als KI lässt sich ein lokal betriebenes Modell einsetzen, sodass keine Inhalte an einen externen Dienst gehen.
Intentron selbst ist kein KI-Produkt, das Sie einsetzen, sondern der Rahmen, in dem Ihre eigene Software entsteht. Wenn Sie darüber hinaus Entwicklungsleistung brauchen, etwa weil eine Erweiterung nur für Ihr Haus gebaut werden soll, übernimmt das die Owlist GmbH. Auch diese Arbeit läuft nach denselben Regeln, die auf dieser Seite beschrieben sind.
Nein. Das Framework ersetzt weder einen externen Sicherheitstest noch eine juristische Prüfung Ihres konkreten Falls, und es garantiert keine Fehlerfreiheit. Was es leistet, ist Nachvollziehbarkeit von jeder Änderung zurück zur Absicht und das frühe Abfangen von Regelverstößen. Auf Dokumentationspflichten, wie sie DSGVO und EU AI Act mit sich bringen, zahlt das direkt ein.
Das ist der häufigste Grund, warum Regelwerke scheitern, und deshalb ist die Strenge einstellbar. Sie beginnen in der Stufe, die zum Risiko passt. Und einzelne Prüfungen dürfen mit Begründung abgeschaltet werden, statt still umgangen zu werden. Genau diese Begründungen sind es, die später tragen.
Sie brauchen kein Projekt und keinen Termin, um zu sehen, ob diese Arbeitsweise zu Ihnen passt. Nehmen Sie ein Vorhaben, das bei Ihnen ohnehin ansteht, und schreiben Sie dafür einmal auf, was herauskommen soll. Der Intent-Chat-Skill führt Sie hindurch.
Sie wollen über das Framework selbst sprechen? Schreiben Sie an info@owlist.ch.