G|AI Works G|AI Works
EN | DE

Über

Angewandte KI, eingebaut in echte Systeme.

G|AI Works ist ein inhabergeführtes Applied-AI-Studio von Oliver Gruenig. Strategie, Engineering, Integration und Betrieb aus einer Hand — produktionsreif ab Sprint eins, mit Audit-Trails, messbaren Ergebnissen und ohne proprietäre Plattform- oder Runtime-Abhängigkeit.

Inhabergeführt von

Oliver Gruenig

Strategie · Engineering · Integration · Betrieb — end-to-end, unter einem verantwortlichen Inhaber.

—Sitz in Karlsruhe, DE
—Remote in der EU · vor Ort im DACH-Raum
—Antwort typisch in 24–48 h
Scoping-Gespräch starten Referenz-Engagements ansehen

Warum G|AI Works existiert

Die meisten KI-Projekte enden an der gleichen Stelle: ein Demo, das funktioniert — und ein Produktionspfad, der nicht existiert. Das Problem ist nicht das Modell, sondern das fehlende Machbarkeitsdenken vor dem Bauen.

Welche Daten sind tatsächlich verfügbar und sauber genug? Welche Governance hält unter echtem Betriebsdruck? Was bedeutet „fertig" gemessen an eurem konkreten Stack? Ohne klare Antworten scheitern selbst technisch solide Systeme an der Integration.

G|AI Works beginnt dort. Ein verantwortlicher Owner, fester Scope, produktionsreif ab Sprint eins — mit einer strukturierten Machbarkeitsprüfung vor jeder Architekturentscheidung.

Arbeitsüberzeugungen

Woher ich bei dem Thema komme

  • Machbarkeit vor Architektur.

    Bevor Modell- oder Infrastrukturentscheidungen getroffen werden, werden verfügbare Daten, Systemgrenzen und Governance-Anforderungen kartiert. Was der Stack tatsächlich trägt, bestimmt, was wir bauen — nicht das theoretische Ceiling des Modells.

  • Die meisten KI-Projekte scheitern an Integration, nicht am Modell.

    Die interessante Arbeit liegt dort, wo ein LLM auf ERP, Data Warehouse, internes Tool oder Content-System trifft. Genau an dieser Schnittstelle arbeite ich.

  • Evaluation vor Design-Entscheidungen.

    Ein Eval-Harness mit definierter Baseline läuft ab Sprint eins. Entscheidungen zu Prompts, Modellen und Struktur fallen gegen diese Baseline — nicht nach Geschmack.

  • Ein Deliverable, das ihr ohne mich nicht betreiben könnt, ist kein Deliverable.

    Jedes Engagement endet mit einem Übergabepaket — Runbook, Prompt-Registry, Eval-Suite, Dokumentation — damit das System an Tag 181 auch ohne mich im Raum läuft.

  • Produktionsreif ist Default, kein Upgrade.

    Versionierte Prompts, strukturierte Output-Validierung, Rollback-Pfade und Kosten-Instrumentierung sind ab dem ersten Commit drin — nicht kurz vor Go-live draufgeschraubt.

Technisches Profil

Stack und Projektformate

Ein Arbeitsprofil, keine Einkaufsliste. Diese Werkzeuge und Projektformate kommen in echten Engagements wiederholt zum Einsatz — ausgewählt, weil sie unter Produktionslast tragen, nicht weil sie gerade im Trend liegen.

// Sprachen

  • · TypeScript
  • · Python
  • · SQL
  • · Shell

// KI & LLM

  • · Claude (Sonnet / Opus)
  • · OpenAI-Modelle
  • · Multi-Agent-Orchestrierung
  • · Structured Output + Schema-Validierung
  • · Retrieval auf eigenen Daten
  • · Eval-Harness

// Plattformen & Daten

  • · Astro · Node · Tailwind
  • · Postgres · SQLite
  • · Data Warehouses
  • · ERP- / CRM-Konnektoren
  • · REST- & RPC-APIs

// Operativ

  • · Prompt-Registry
  • · Versionierte Output-Schemas (Pydantic / Zod)
  • · Observability & Kosten-Instrumentierung
  • · CI-Eval-Gates
  • · Rollback-Tooling

// Typische Projektformate

  • — AI Readiness Audit, bevor ein System in Produktion geht
  • — Prototype-to-Production-Sprint für einen klar umrissenen Workflow
  • — Hardening eines bestehenden KI-Systems — Eval-Gates, Observability, Kostenkontrolle, Security
  • — Interne Copiloten und Multi-Agent-Workflows für echte Business-Aufgaben
  • — LLMs in ERPs, CMSs und Data Warehouses integrieren
  • — Company Memory und Wissensretrieval-Systeme entwerfen

Meta-Proof

Wie diese Website tatsächlich produziert wird

Diese Website wird von genau der Klasse von System betrieben, die ich auch für Kunden baue: eine Multi-Agent-Redaktionspipeline, in der jede Rolle ein eigener Agent mit versioniertem Prompt ist, mit expliziten Inputs und Outputs und einem Qualitäts-Gate. EN wird zuerst verfasst, DE in abgestimmten Varianten produziert — und jeder Entwurf passiert vier Gates, bevor er live geht: SEO, Security, Sources, Clarity.

// Pipeline

  1. 01 Trend Scout sonnet-4-6 findet Themen, prüft Quellen
  2. 02 Pillar-Writer sonnet-4-6 Erstentwurf pro Domäne — Tech, Marketing, Finance
  3. 03 Fact & Source Checker sonnet-4-6 verifiziert Aussagen, markiert schwache Quellen
  4. 04 SEO Architect sonnet-4-6 Struktur, Metadaten, interne Verlinkung
  5. 05 Security Reviewer sonnet-4-6 entfernt Exploit-Pfade, setzt Safe-Defaults durch
  6. 06 Lead Editor opus-4-6 finales Gate — freigegebene Entwürfe werden in die Collection geroutet

Dasselbe architektonische Muster läuft in Kundenprojekten — anderes Thema, gleiche operative Disziplin: versionierte Prompts, explizite Verträge zwischen den Rollen und ein Audit-Trail für jede Entscheidung.

Zwei reale Fälle sind auf unterschiedlichen Offenlegungsstufen dokumentiert: die gruenig.com Content-Pipeline (intern, voll offengelegt) und ein vertikales B2B-Vergleichsportal (Kunden-Engagement, redigiert).

Kompetenzen

Arten von Systemen, die ich baue

Vorgehen

Fester Scope. Definierte Ergebnisse.

Jedes Engagement beginnt mit einem Daten-Audit und endet mit einem Übergabepaket: Runbook, Prompt-Registry, Eval-Suite und vollständige Dokumentation. Deliverables, Timeline und Erfolgskennzahl werden schriftlich vereinbart, bevor Code geschrieben wird. Keine offenen Retainer. Kein Scope-Creep. Nach der Übergabe gehört das System vollständig euch.

Projekt starten →