Beweis statt Bauchgefühl: Wie mathematisch verifizierte Agenten den Bias-Schutz lösen

Es gibt eine Beobachtung aus unseren laufenden Pilots, die wir inzwischen mit fast jedem CMO-Office in der ersten Architektur-Session teilen. Ein Agent skaliert, was er sieht — und er skaliert es konsequent. Wenn die Signal-Daten, die ihm zur Verfügung stehen, eine Schieflage haben (kanalseitig, demografisch, geografisch), dann skaliert der Agent diese Schieflage einfach mit. Klassische Software-Qualitätssicherung — Unit-Tests, Integration-Tests, End-to-End-Tests — fängt dieses Problem nicht ab. Diese Tests prüfen Stichproben. Sie prüfen die Frage: 'Funktioniert mein Code bei diesen tausend Beispielen?' Sie prüfen nicht die Frage: 'Funktioniert mein Code für alle möglichen Inputs, die in der Produktion auftauchen können?' Genau diese zweite Frage wird im agentischen Setup zur Schlüsselfrage. Was schief in den Agent reingeht, kommt KI-gesteuert schief raus, nur schneller.

Das Bias-Problem im agentischen Marketing zerfällt dabei in mehrere konkrete Gestalten. Der bekannteste ist der Conversion-Bias: ein Agent, dem primär conversion-lastige Daten zur Verfügung stehen, optimiert primär auf das, was schnell konvertiert. Upper- und Mid-Funnel hungern aus, Brand-Effekte werden übersehen. Ein zweiter ist der demografische Bias: wenn die Trainingsdaten eines Lookalike-Modells systematisch ein bestimmtes Segment unterrepräsentieren, skaliert der Agent diese Unterrepräsentation ungebremst. Ein dritter ist der Channel-Bias: wenn ein Kanal aus Tracking-Gründen besser instrumentiert ist als ein anderer, sieht der Agent mehr Wirkung dort und investiert dort weiter — unabhängig davon, ob das die tatsächliche kausale Wirkung ist. Diese drei Verzerrungen sind nicht hypothetisch. Sie sind die Standard-Fehlerquellen, die in jedem agentischen Setup ohne aktiven Bias-Schutz entstehen.

Die übliche Reaktion auf dieses Problem ist organisatorisch: man fordert vom Marketing-Team Bias-Awareness, definiert ein paar Guardrails, hofft auf gesunden Menschenverstand und revidiert die Setups vierteljährlich. Das ist nicht falsch. Es ist nur nicht ausreichend, wenn der Agent in Echtzeit-Feeds Entscheidungen trifft. Was wir innerhalb der opua-Brand-Family seit Anfang 2025 systematisch aufbauen, ist deshalb eine zweite Sicherheits-Ebene neben der organisatorischen — eine mathematische. Sie beantwortet die Frage 'ist diese Eigenschaft für alle möglichen Inputs garantiert' mit einem maschinengeprüften Theorem statt mit einem Test, der zufällig diesen spezifischen Input nicht trifft. Das Werkzeug, mit dem wir das tun, heisst Lean 4.

Lean 4 ist ein moderner Theorem-Prover aus Microsoft Research, der seit etwa 2021 mathematische Beweise und Software-Verifikation in einer einzigen Sprache vereint. In der akademischen Mathematik hat sich Lean 4 schnell etabliert — das Liquid Tensor Experiment hat damit einen Theorem von Peter Scholze formal verifiziert, und ein wachsender Teil der zeitgenössischen Mathematik landet inzwischen direkt in Lean-Bibliotheken. In der industriellen Anwendung ist Lean 4 in den letzten zwei Jahren von der Nische in die Breite gewandert. Cloudflare verifiziert damit kryptografische Bibliotheken, AWS Teile ihrer Konsens-Protokolle, ein wachsender Teil der DeFi-Welt ihre Smart-Contract-Logik. Was diese Anwendungen verbindet, ist eine gemeinsame Eigenschaft: sie sind kritisch genug, dass ein Stichproben-Test nicht ausreicht. Marketing-Agenten gehören zu dieser Kategorie, sobald sie autonom Budgets im sechs- oder siebenstelligen Bereich allokieren.

Unsere Schwester-Plattform Nexbid — das agentische Ad-Tech-Stack innerhalb der opua-Brand-Family — hat siebenundvierzig Lean-4-Theoreme für ihre Auction-Engine formal verifiziert. Diese Theoreme decken vier Eigenschaftsklassen ab. Erstens Truthfulness: jeder rationale Bieter sollte seine wahre Bewertung bieten, und der Mechanismus muss garantieren, dass strategisches Untertreiben oder Übertreiben dem Bieter schadet. Zweitens Pareto-Effizienz: die Auktion sollte das Inventar an denjenigen vergeben, der den höchsten Nutzen daraus zieht. Drittens Revenue-Equivalence: unter definierten Bedingungen muss die erwartete Einnahme des Verkäufers über verschiedene Mechanismen hinweg gleich sein. Viertens Manipulation-Resistance: kein einzelner Akteur darf das Ergebnis durch Side-Information-Strategien systematisch beeinflussen können. Diese vier Eigenschaftsklassen sind nicht durch Unit-Tests abgesichert, sondern durch Beweise, die der Lean-Compiler in der Continuous-Integration-Pipeline neu prüft, sobald jemand auch nur eine Zeile in der Auction-Logik ändert.

Das gleiche Pattern überträgt sich auf Marketing Mix Modeling. In unserem mmm-wizard-verification-Sub-Repository sind aktuell die ersten neunzehn Theoreme produktiv, weitere folgen im laufenden Sprint. Die Eigenschaften, die hier geprüft werden, sind für regulierte Industrien zentral. Budget-Konservierung: die Summe der empfohlenen Channel-Budgets ist exakt gleich der Summe der aktuellen Channel-Budgets. Non-Negativity: keine Empfehlung schlägt einen negativen Spend vor. Determinismus: derselbe Input plus derselbe Seed liefert bit-identische Outputs, drei Monate später noch reproduzierbar. Monotonie: wenn ein Channel mehr historische Performance zeigt, schlägt das MMM bei sonst identischen Parametern keine Reduktion vor. Diese vier Eigenschaften sind genau das, was ein Compliance-Officer in einer Schweizer Bank wissen will, bevor er eine MMM-getriebene Budget-Verschiebung freigibt — und sie sind hier nicht versprochen, sondern bewiesen.

Für ein CMO-Office macht es Sinn, diese Stufung explizit zu adressieren, weil sie die Sprache verändert, in der man mit Audit, Legal und CFO spricht. Stufe null ist 'wir testen nicht'. Diese Stufe ist in der Branche überraschend häufig. Stufe eins ist 'wir testen mit Unit- und Integration-Tests'. Das ist das industrielle Mindestmass, aber es prüft eben nur Stichproben. Stufe zwei ist 'wir prüfen kritische Eigenschaften formal mit einem etablierten Theorem-Prover'. Das ist die Stufe, auf der unsere Plattform arbeitet. Wenn ein CFO oder ein Compliance-Officer fragt: 'Wie garantieren Sie mir, dass keine negative Budget-Empfehlung auftaucht?', dann ist die Antwort nicht 'wir haben tausend Tests', sondern 'hier ist der Lean-4-Beweis, hier ist das Repository-File, hier ist die Continuous-Integration-Run-ID der letzten erfolgreichen Verifikation'. Das ist ein qualitativ anderes Gespräch.

Aus regulatorischer Sicht bekommt diese Stufung in Europa eine zusätzliche Dimension. Artikel 22 des revidierten Datenschutzgesetzes der Schweiz und Artikel 22 der EU-DSGVO verlangen erklärbare automatisierte Entscheidungen. Eine Bayesian-Pipeline mit MCMC-Samples ist statistisch korrekt, aber für einen internen Audit ohne weiteres nicht prüfbar. Ein machine-checked Lean-4-Beweis ist hingegen die belastbarste Form der Erklärbarkeit, die ein Software-Anbieter heute liefern kann. Er ist robuster als 'wir haben gute Tests', robuster als ein Code-Review-Approval, und er hängt nicht vom Urteil eines einzelnen menschlichen Prüfers ab. Wer eine Marketing-Empfehlung in einer Bank gegen einen internen Audit verteidigen muss, kann den Lean-4-Beweis als Anhang zum Audit-Report mitliefern. Wer das nicht kann, hat in einer regulierten Industrie ein strukturelles Wachstums-Problem.

Strategisch ist dieser Beweis-Layer das, was die opua-Brand-Family von einer normalen Marketing-Tech-Plattform unterscheidet. Nexbid verifiziert Auctions. mmm-wizard verifiziert Budget-Allokation. Mineralis, unser Tool für Mining- und Energy-Equity-Research, wird das gleiche Pattern auf Equity-Recommendation-Properties anwenden — etwa 'die Empfehlung folgt monoton den fundamentalen Bewertungs-Kennzahlen'. Was wie eine technische Spezialität klingt, ist eine architektonische Entscheidung: jede Brand innerhalb der opua-Familie nutzt das gleiche Verification-Pattern. Das erzeugt drei Effekte. Cross-Brand-Konsistenz im Audit-Modell, geteilte Investition in Tooling und Theorembibliotheken, und ein verteidigbarer USP gegen Generalist-Plattformen, die auf 'wir haben gute Tests' setzen. Wer das Pattern produktiv im Repository sehen will, findet die Theoreme öffentlich.

Die siebenundvierzig Nexbid-Auction-Theoreme und die neunzehn mmm-wizard-Theoreme sind im Repository github.com/nexbid-dev/protocol-commerce einsehbar, lizensiert unter MIT. Wer als CTO, Compliance-Officer oder Tech-Investor das Pattern in einer eigenen Software-Evaluation prüfen will, kann unter audit@digital-opua.ch ein vertieftes Theoreme-Walkthrough anfragen. Wer den DCM Agent Orchestrator live sehen will, in dem dieser Verification-Layer als Compliance-Surface eingebunden ist, kann sich unter demo@digital-opua.ch für die Pre-Beta eintragen. Drei Fragen helfen dabei, Software-Anbieter zu evaluieren. Welche Properties prüft die Pipeline maschinell? Sind die Theoreme im Repository öffentlich einsehbar? Wie ist die Continuous-Integration-Integration? Wer diese drei Fragen klar beantworten kann, hat einen Bias-Schutz, der hält. Wer es nicht kann, hat eine Folie.