Fragen, die man beantworten sollte

RFI-IRFOS ist ein eingetragenes österreichisches Not-for-Profit (ZVR 1015608684), entstanden 2020 aus einem interdisziplinären Forschungskollektiv in Vorarlberg. Wir arbeiten an ternären KI-Systemen, World-Model- und Evidenzgraph-Forschung sowie Agent-Evaluation, mit albert. und DINGIR als den zwei Projekten, die den Rest zusammenhalten, unaufgeforderte Sicherheitsforschung ist ein Strang dieser Arbeit, nicht die ganze. Wir bleiben absichtlich interdisziplinär, die Probleme, die uns interessieren, halten sich selten an die Grenze zwischen einem Feld und dem nächsten.

Ein Large Language Model sagt Text anhand gelernter Muster voraus und erzeugt ihn. Es ist eine Komponente, mit der und um die wir bauen, kein vollständiges System für sich, deshalb trainieren wir mit albert. auch unser eigenes ternäres LLM, statt ein LLM als das ganze Produkt zu behandeln. Ein Modell, das nur das nächste Token vorhersagt, kann nicht selbst prüfen, ob das eben Gesagte stimmt, diese Prüfung muss von woanders im System kommen.

Ein Agent verbindet ein Modell, Werkzeuge und Beobachtungen, um selbstständig ein Ziel zu verfolgen und zu handeln. Wir setzen Agenten in sehr unterschiedlichen Teilen unserer Arbeit ein: beim Einspeisen und Prüfen von Behauptungen in DINGIR, unser World Model, bei Aufgabensuiten für Kunden-Agent-Evaluationen, und beim Gegenprüfen von Evidenz für die Sicherheitsforschung, die wir veröffentlichen, immer mit einem Menschen, der prüft, bevor etwas rausgeht. Dieses menschliche Gate behalten wir, weil ein Agent, der handeln kann, auch auf einem falschen Befund handeln kann, und der Preis dafür ist real, kein einfacher Neuversuch.

Ein World Model hält ein strukturiertes, sich veränderndes Bild von Entitäten, Beziehungen und Ursachen bereit, damit eine Behauptung an der Realität geprüft werden kann, statt nur plausibel zu klingen. Unseres heißt DINGIR: ein Graph, der seine Topologie mit einem neuronalen Netz lernt und jede Behauptung mit einem ternären Zustand versieht, bestätigt, ungeklärt oder widerlegt, nie ein flaches Ja. Das flache Ja verweigern wir bewusst, die meisten Systeme, die Gewissheit behaupten, verstecken damit nur die Fälle, in denen sie sich nicht sicher waren.

Ein Data Warehouse führt Informationen aus vielen Quellen an einem konsistenten, abfragbaren Ort zusammen. Unseres bauen wir aus der Evidenz, die unsere eigene Forschung ohnehin erzeugt, World-Model-Beobachtungen, Agent-Safety-Trajektorien, App-Verhaltensdaten, und bieten sie über unsere Data-Solutions-Linie als strukturierte, herkunftsnachvollziehbare Daten an, nicht nur intern gehalten. Die Arbeit, diese Evidenz zu erzeugen, ist bereits einmal passiert, wir sahen keinen Grund, eine Kundschaft dafür zahlen zu lassen, dass wir sie von Grund auf wiederholen.

Unseren eigenen Stack: eine von Grund auf gebaute ternäre Logik-Runtime, nicht aus binären KI-Frameworks abgeleitet, albert., unser selbst trainiertes ternäres LLM, DINGIR, unser Evidenzgraph-World-Model, Rust- und Axum-Backend-Services, und das Werkzeug hinter über 300 Android-Security-Audits. Dasselbe Team baut alles davon, weil wir nur für ein System, das wir Ende-zu-Ende verstehen, wirklich einstehen können, wenn darin etwas nicht stimmt.

Jeder Schritt dessen, was wir bauen, ist nachvollziehbar und einsehbar, nicht hinter der Blackbox eines Anbieters versteckt. Wir verstehen uns als die Whitebox-Entsprechung zu Systemen wie Palantir: dieselbe Kategorie an Fähigkeit, aber man sieht, wie eine Schlussfolgerung zustande kam, statt sie nur glauben zu müssen. Dieser Unterschied zählt nur, wenn wir uns selbst daran halten, deshalb gilt dieselbe Nachvollziehbarkeit für unsere eigenen Befunde, nicht nur für die Systeme, die wir verkaufen.

Ja, und wir prüfen sie auch auf Manipulation, nicht nur, dass sie geloggt werden. Unsere internen Systeme verankern die Audit-Historie außerhalb der eigentlichen Datenbank, damit ein wiederhergestelltes Backup oder eine nachträglich veränderte Zeile automatisch auffällt, statt zufällig entdeckt zu werden. Ein Log, für das nur dieselbe Datenbank bürgt, ist keine wirklich unabhängige Evidenz, sondern nur eine zweite Kopie derselben Behauptung.

Wir vereinbaren die Umgangsregeln mit einer Kundschaft, bevor wir überhaupt etwas anfassen, minimieren was wir erheben, und halten Test- und Forschungsdaten standardmäßig von allem Identifizierenden getrennt. Bei der unaufgeforderten Sicherheitsforschung, die wir veröffentlichen, gehen wir weiter, es werden auch keine personenbezogenen Daten veröffentlicht, nur die technischen Fakten und die Antwort des Unternehmens, unter einem festen Embargo, egal ob geantwortet wird. Veröffentlichung sollte nie davon abhängen, ob uns jemand fürs Schweigen bezahlt, deshalb tut sie das auch nicht.

Nein. Private Daten, Umgebungen und Ergebnisse einer Kundschaft bleiben privat, außer sie geben eine ausdrückliche Freigabe. Daneben betreiben wir auch eigene unaufgeforderte Sicherheitsforschung zu öffentlichen Apps, die einer anderen, festen 90-Tage-Offenlegungsfrist folgt, die unabhängig von einer Zahlung gleich gilt, eine zahlende Kundschaft und ein unbeteiligter App-Anbieter sind nicht dieselbe Beziehung und sollten nicht derselben Regel unterliegen.

Nein. Wir prüfen Unternehmen, die bei der Datenerhebung übers Ziel hinausschießen, wir bauen das Übersteigen nicht selbst. Diese Grenze gilt unabhängig davon, wer fragt oder was geboten wird, weil unsere Audits nur deshalb Gewicht haben, weil wir selbst nie auf der anderen Seite eines solchen standen.

Nein. Jeder Befund in unseren Sicherheits-Offenlegungen stammt aus dem Dekompilieren einer öffentlichen App oder dem Lesen der eigenen veröffentlichten Richtlinie eines Unternehmens, nie daraus, eine Mitarbeiterin oder einen Support-Kontakt zur Herausgabe von etwas zu bewegen. Dieser Maßstab gilt über Offenlegungen hinaus, wir manipulieren nirgends in unserer Arbeit Menschen, um an Informationen zu kommen, egal um welche Forschungsfrage es geht.

Nein. Das ist die eine Grenze, die sich bei keiner Scope-Verhandlung verschiebt, egal welche Kundschaft, welches Budget, welche Frist. Eine Grenze, die unter genug Druck nachgibt, war nie wirklich eine Grenze, sondern nur ein Startangebot.

Wir entwerfen die Antwort auf "warum hat das System das gemacht", bevor die erste Zeile Code geschrieben wird, nicht erst, nachdem uns ein Vorfall dazu zwingt. Jede DINGIR-Behauptung trägt genau deshalb ihren eigenen Vertrauenszustand und ihre Quellenkette. Eine Erklärung nachträglich anzuflicken heißt meist, sich im Nachhinein eine passende Geschichte zu suchen, das ist nicht dasselbe wie zu wissen, warum etwas wirklich passiert ist.

Artikel 13 (Transparenz), 14 (menschliche Aufsicht) und 15 (Genauigkeit, Robustheit, Cybersicherheit) sind Referenzpunkte, gegen die wir direkt entwerfen, keine Compliance-Punkte, die erst nachträglich draufgesetzt werden. Erst nach dem Launch auf einen Gesetzesartikel hinzubauen bedeutet meist, Logs und Disclaimer um bereits getroffene Entscheidungen herumzubauen, derselbe oberflächliche Fix wie nachträgliche Explainability.

Ja. Wir bauen Aufgabensuiten um eure echten Werkzeuge, instrumentieren die Tool-Nutzung Schritt für Schritt, labeln Fehler- und Sicherheitskategorien und liefern einen Bericht, der in echten Trajektorien verankert ist, nicht in einem generischen Benchmark-Score. Ein Benchmark-Score sagt, wie ein Agent bei fremden Aufgaben abgeschnitten hat, nicht bei euren, und das ist selten dasselbe.

Ja. Containerisiert, deterministische Resets, kontrollierte Testzugänge, die nie an Produktivsysteme rühren, dasselbe Setup, das wir für unsere eigenen Agent-Safety-Evaluationen nutzen. Wir legen an fremde Arbeit denselben Maßstab an wie an unsere eigene, sonst würde das Wort "Test" nichts bedeuten.

Denselben versionierten Input auch in einem Jahr wieder gegen dieselbe Umgebung laufen lassen und einen prüfbaren Nachweis bekommen, was sich verändert hat und warum, nicht nur ein ähnlich aussehendes Ergebnis. Ein Ergebnis, das sich nicht reproduzieren lässt, ist eine Anekdote, egal wie überzeugend es beim ersten Mal wirkte.

Wir führen eine Untersuchung auf Root-Ebene im App-Binary durch, keine Oberflächenprüfung, kontaktieren das betroffene Unternehmen über einen koordinierten, schriftlichen Kanal mit Aufsichtsbehörden in Kopie, und veröffentlichen die Befunde nach einem festen 90-Tage-Embargo, egal ob je geantwortet wird. Die Behörde von Anfang an in Kopie zu setzen heißt, dass wir nie die Einzigen sind, die wissen, was wir gefunden haben, genau das ist der Punkt.

Schickt uns ein konkretes Ziel, eine Grenze oder ein System, das ihr wirklich verstehen wollt, keine Wunschliste. Wir definieren von da aus den kleinsten sinnvollen ersten Schritt, weil ein erstes Engagement, das alles auf einmal beweisen will, meist nichts davon richtig beweist.