Compliance-Aware Retrieval-Augmented Generation for Regulated Financial-Reporting Corpora: A Real-World Evaluation on SEC EDGAR Filings

Q: Do you work on pure equity?

I love working with ambitious founders, and I happily structure hybrid engagements — a reduced service fee combined with equity — when the fit is right. Pure-equity arrangements, however, aren't something I take on. A service fee is required on every project: it ensures focused delivery, protects both sides against misaligned timelines, and keeps the engagement sustainable the same way any senior technical hire is compensated. If you're an early-stage founder, let's talk — there's almost always a structure that works.

Q: How much does a Fractional CTO cost in Europe?

Hourly consulting is €150/hour, day rate is €700/day. Ongoing Fractional CTO retainers start from about €2,100/month for a 2-3 days/month minimum and scale up with the cadence — a 1-day-a-week engagement typically lands between €5,000–€8,000 per month depending on scope. Partnership deals (reduced fee + equity) are available for aligned early-stage startups. All prices exclude VAT and French TVA applies where relevant; EU B2B clients with a valid intra-community VAT number benefit from reverse charge.

Q: Fractional CTO vs full-time CTO — which should I hire?

Hire a full-time CTO when the role genuinely needs 40+ hours/week of executive tech leadership — usually post-Series A with 10+ engineers, a real product in market, and a 3-year roadmap. Hire a Fractional CTO when you need senior technical leadership but: you're pre-seed to Series A, your engineering team is under 10 people, you want to validate the product before committing to a cap-table-impacting hire, or you need a specific expertise (AI strategy, EU compliance, sovereign cloud) that a generalist full-time CTO wouldn't bring.

Q: How does the Partnership model work?

It's a hybrid engagement: a reduced cash rate (typically 30-40% of my standard) combined with equity. The exact split is discussed case by case after we've talked through your stage, timeline, runway, and goals. The service-fee component is always present; it's what keeps the engagement focused and fair to both sides.

Q: What's a typical engagement duration?

Consultations run 30 or 60 minutes. MVPs typically ship in 4-8 weeks. Fractional CTO engagements are usually 2-3 days per month minimum, with the cadence scaling up based on traction and fit. Shorter sprint engagements (1-2 weeks) are also possible for well-scoped prototypes.

Q: Can you help with EU AI Act compliance?

Yes. I help companies classify their AI systems by risk tier (prohibited / high-risk / limited-risk / minimal-risk), implement the technical documentation and post-market monitoring required by Articles 9-15, align with GPAI obligations for foundation-model users, and produce the DPIA, Transfer Impact Assessments (Schrems II), and Article 28 DPAs needed. I also cross-walk with GDPR, NIS2, DORA (for financial services), and ISO/IEC 42001 / 23894. Sign-off always rests with your DPO or legal counsel; what I deliver is a defensible, documented compliance posture.

Q: Can you help us migrate from OpenAI to sovereign infrastructure?

Yes — this is becoming a common request from European companies facing compliance pressure or customer procurement scrutiny. Typical path: audit current OpenAI/Anthropic usage, map workloads by quality/latency/cost sensitivity, select replacement targets (Mistral Large for most chat, self-hosted Llama-3 or Mixtral for sensitive data, Claude Sonnet via Bedrock EU where acceptable), build an eval harness that proves parity, migrate behind a feature flag, and cut over gradually. End state: zero prompt/response egress to non-EU jurisdictions, with an auditable trail.

Q: Do you work with non-technical founders?

Yes — this is one of my most common engagements. Non-technical founders hire me to make the build vs buy decision, run the first hiring, set up the stack, ship the MVP, and represent the company technically with investors, partners, and early customers. I translate between product intent and engineering reality, and write everything in plain language so the founder stays in the loop without needing to code.

Q: Do you work remote or on-site?

Remote-first, based in Paris. I'm open to on-site days in Paris and short on-site sprints across Europe for the right engagements. Most clients are 100% remote with weekly syncs and async daily updates.

Q: How quickly can you start?

Usually within 1-2 weeks of signing. For urgent MVPs or discovery sprints I can often kick off within days, starting with a scoped 3-5 day discovery phase before we commit to the full build.

Bhardwaj, Aru

Zurück zur Forschung

Forschung · Arbeitsentwurf · 2026

Compliance-bewusste Retrieval-Augmented Generation für regulierte Finanzberichts-Corpora

Eine reale Evaluierung anhand von SEC-EDGAR-Einreichungen.

Aru Bhardwaj · Insightrix, Frankreich · 33 Seiten · 2026

Arbeitsentwurf — Feedback willkommen an bonjour@arubhardwaj.eu

ENDas PDF ist nur auf Englisch verfügbar. Unten folgt eine übersetzte Zusammenfassung der Kernpunkte.

81.12%

0.00%

Constraint-Verletzungen

21.29%

0.00%

Output-Disclosures

—

4.8 pts

F1-Kosten

—

0 ms

p95-Latenz-Overhead

Kurzfassung

Standard-RAG holt das, was am relevantesten ist. In regulierten Branchen ist das Relevanteste nicht zwangsläufig das Erlaubte. Eine Passage kann der beste Match für eine Anfrage sein und dennoch für diesen Nutzer, diesen Zweck, diese Sitzung unzulässig — unter DSGVO, EU AI Act, Reg FD, FINRA, SOX oder HIPAA.

CARAG (Compliance-Aware RAG) ist eine fünfstufige Architektur, die Compliance als erstklassige Eigenschaft des Index, des Retrievers, des Generators und des Audit-Logs behandelt. Das Paper veröffentlicht einen Benchmark aus 6.000 echten SEC-EDGAR-Einreichungen (26.595 Chunks über sieben Quartale), mit Policy-Vektoren aus dokumentierten Submission-Feldern statt synthetischen Verteilungen.

Auf dem Hauptbenchmark senkt CARAG die Constraint-Violation-Rate von 81,12 % auf 0,00 % und die Output-Disclosure-Rate von 21,29 % auf 0,00 %, opfert dabei nur 4,8 F1-Punkte und fügt 0 ms 95-Perzentil-Latenz gegenüber einer Vanilla-RAG-Baseline hinzu.

Warum das in Produktion zählt

Drei reale Deployments motivieren die Architektur — operativ verbreitet, aber architektonisch unhandlich für Vanilla-RAG:

1
Sell-Side-Aktienresearch. Ein Vanilla-Retriever zeigt das jüngste 10-K eines Analysten neben einem privat in Auftrag gegebenen Modell, dessen Deal-Team der Analyst nicht angehört, und einem veralteten 10-Q, das durch einen Nachtrag abgelöst wurde. Veröffentlicht aus der zweiten Quelle: regulatorische Strafe; aus der dritten: analytischer Fehler.
2
Klinische Entscheidungsunterstützung. Eine Krankenpflegekraft fragt nach einem Patienten. Der Retriever zeigt relevante Notizen eines Spezialisten außerhalb der Behandlungsbeziehung — unzulässig nach HIPAAs Minimum-Necessary-Regel, selbst innerhalb desselben Krankenhauses.
3
Cross-Border-Analytik. Ein globaler Asset Manager in Frankfurt führt RAG über EU-, US- und Singapur-resident Einreichungen aus. Unter DSGVO Artikel 6 schränkt die Rechtsgrundlage, unter der ein EU-resident Dokument indiziert wurde, die Zwecke ein, für die es abgerufen werden darf — pro Dokument, nicht pro Nutzer.

In allen drei Fällen sind die Dokumente legitim, der Nutzer autorisiert, die Frage vernünftig — und die Schnittmenge zum Retrieval-Zeitpunkt dennoch unzulässig. Genau diese Schnittmenge muss RAG zu berechnen lernen.

Vier Fehlermodi compliance-naiver RAG-Systeme

F1

Index-Zeit-Leak

Ein Dokument wird indiziert, ohne zu prüfen, ob der Ingestion-Kontext das System dazu berechtigte. Sobald der Chunk im Index ist, sieht ihn jede nachgelagerte Anfrage unabhängig von der Policy.

F2

Retrieval-Zeit-Leak

Der Chunk ist korrekt etikettiert, aber der Retriever konsultiert das Etikett nicht, daher erscheint er im Top-k für Anfragen, deren Policy ihn verbietet. Der modale Fehler von Vanilla-RAG.

F3

Generation-Zeit-Leak aus unzulässigem Kontext

Der Retriever filtert korrekt, doch der Generator paraphrasiert über Snippets hinweg und synthetisiert Inhalte, die aus einem unzulässigen Chunk stammen.

F4

Generation-Zeit parametrischer Leak

Der Retriever liefert nichts Brauchbares, doch der Decoder gibt selbstbewusst eine Tatsache aus, die er aus seinem Pre-Training rekonstruiert hat — mitunter selbst unzulässig.

CARAG schließt F1–F3 strukturell und F4 probabilistisch.

Die fünfstufige CARAG-Pipeline

1
Ingestion + Policy-Etikettierung
Jeder Chunk erhält einen 27-Bit-Policy-Vektor, gepackt in ein 32-Bit-Maschinenwort — deterministisch abgeleitet aus dokumentierten Metadatenfeldern. ~0,4 % Speicheroverhead bei d=1024, fp16.
2
Metadaten-bewusster Index (HNSW)
Standard Hierarchical Navigable Small World-Graph (M=32, efConstruction=200), mit der Policy-Bitmask neben jedem Vektor co-lokalisiert für O(1)-Zulässigkeitstests pro Kandidat.
3
Policy-Inferenz
Bildet (Anfrage, Nutzerrolle, Sitzungszweck) auf ein (M_req, M_for)-Maskenpaar ab über ein deterministisches Rolle-Policy-Lookup plus einen Sitzungsmodulator, der query-bedingte Verfeinerungen wie die aktive Deal-Liste anwendet.
4
Constraint-bewusster Retriever
Bitweiser Zulässigkeitstest, ausgewertet innerhalb der inneren Schleife der HNSW-Traversierung — bevor der Result-Heap aktualisiert wird. Adaptive ef-Expansion erhält den Recall unter strengen Policies.
5
Bewachter Generator + Merkle-verankertes Audit-Log
Der Generator (Amazon Nova Micro) sieht zulässige und unzulässige Buckets explizit und ist angewiesen, nur aus ersterem zu schöpfen. Jede Anfrage erzeugt einen append-only Merkle-verankerten Eintrag, ausreichend für Artikel 12 des EU AI Act.

Hauptergebnisse

Vier Systeme auf dem SEC-Compliance-Benchmark — n = 600 Anfragen, k = 8 abgerufene Chunks pro Anfrage. CARAG erreicht die niedrigste CVR und ODR und opfert dabei nur eine kleine Konstante von Token-F1.

System	CVR ↓	ODR ↓	Refusal	F1	p95 (ms)
B0 Vanilla RAG	81.12%	21.29%	24.90%	0.096	41,498
B1 Post-filter	0.00%	0.00%	23.69%	0.085	41,219
B2 Pre-filter (RBAC)	32.53%	9.64%	22.89%	0.085	41,944
CARAG (full)	0.00%	0.00%	40.56%	0.048	41,005

Tabelle 2, Abschnitt 6.1. CVR = Constraint-Violation-Rate, ODR = Output-Disclosure-Rate. Der Pre-Filter (B2) erreicht denselben CVR-Boden wie CARAG, aber zum Preis eines deutlichen F1-Abfalls, weil eine statische Rollenpartition zu grob ist, um query-bedingte Zulässigkeit zu rekonstruieren.

Wo die Kosten liegen

Die Aufschlüsselung nach Anfragestratum (loose / medium / tight) zeigt, wo die architektonischen Kosten von Compliance fallen. Bei loose-Anfragen — wo die Policy die Mehrheit der relevanten Chunks zulässt — folgt CARAGs F1 eng der Vanilla-Baseline. Die Lücke öffnet sich leicht bei medium-Anfragen und vollständig bei tight-Anfragen, wo die relevante Menge wirklich dünn ist.

Genau dieses tight-Stratum ist auch dort, wo CVR und ODR am wichtigsten sind: jede Verletzung ist konstruktionsbedingt semantisch bedeutsam — ein unzulässiger Chunk enthält die Antwort. Die Kosten konzentrieren sich exakt dort, wo Policy die relevante Menge substanziell einschränkt, nicht bei routinemäßigen Due-Diligence-Anfragen.

Produktionsökonomie

Speicheroverhead

~0,4 %

Ein 32-Bit-Wort pro Chunk bei d=1024, fp16. ~4 GB zusätzlicher RAM/Disk für einen Milliarden-Chunk-Index.

Index-Build-Zeit

Vernachlässigbar

Bitmask wird zum Chunk-Emissionszeitpunkt aus bereits verfügbaren Metadatenfeldern berechnet.

Query-Zeit-Compute

O(1) pro Kandidat

Bitweiser Zulässigkeitstest; adaptives ef fügt eine policy-abhängige Konstante hinzu.

Audit-Speicher

~1 KB/Anfrage

~1,2 KB/Anfrage im Produktionslogging, wo jeder abgerufene Chunk auch Similarity-Score und Policy-Bits trägt.

Reproduzierbarkeit

Alle Experimente laufen auf Amazon Bedrock eu-west-3, ohne hauseigene GPUs in der Schleife:

Embedding: cohere.embed-multilingual-v3 (1024 Dimensionen, L²-normalisiert)
Generator: amazon.nova-micro-v1:0 (Temperatur 0, max_tokens=80)
Output-Disclosure-Judge: amazon.nova-lite-v1:0 mit strukturierter JSON-Rubrik (κ=0,81 vs. Autorenlabels auf 200 handvalidierten Aufrufen)
Index: hnswlib mit M=32, efConstruction=200, efSearch=64
Corpus: 6.000 SEC-Einreichungen → 26.595 Chunks über 877 einzelne Filer, sieben Quartale (2024Q3–2026Q1)
Bedrock-Gesamtausgaben pro vollständiger Reproduktion: ~3 USD

Was das für Ihren Stack bedeutet

Wenn Sie ein RAG-System betreiben, das Folgendes berührt:

→EU-Jurisdiktionen (DSGVO Artikel 5, 6, 22 + AI Act Artikel 12–15)
→Finanzdienstleistungen (Reg FD, FINRA Rule 2241, SOX / PCAOB AS 2820)
→Gesundheitswesen (HIPAA, DSGVO Artikel 9 besondere Kategorien)
→Grenzüberschreitende Datenresidenz (EU/US/UK/CA/Andere)

…ist Compliance keine Sache mehr, die Sie nachträglich draufsetzen können. CARAGs Bitmask-Kodierung lässt sich in Tagen, nicht Monaten, an einen bestehenden Dense-Index nachrüsten, und das Audit-Log ist unter Artikel 12 des EU AI Act prüfbar.

Diese Arbeit zitieren

@techreport{bhardwaj2026carag,
  author      = {Bhardwaj, Aru},
  title       = {Compliance-Aware Retrieval-Augmented Generation
                 for Regulated Financial-Reporting Corpora:
                 A Real-World Evaluation on SEC EDGAR Filings},
  institution = {Insightrix},
  year        = {2026},
  type        = {Working Draft},
  address     = {Paris, France},
  url         = {https://arubhardwaj.eu/research/compliance-aware-rag-sec-edgar}
}

Bringen Sie CARAG-artige Architektur in Ihren Stack

Genau diese Art Architektur deploye ich als Fractional CTO. Wenn Ihr Team ein RAG-System betreibt, das regulierte Daten berührt — EU, Gesundheitswesen, Finanzen oder grenzüberschreitend — sprechen wir.