Eine kurze Übersicht: was ich anbiete, wie ich preise und wie die ersten Wochen aussehen. Fünf Minuten Lesezeit vor unserem Kennenlerngespräch.
Am besten arbeite ich mit Engineering- und Produkt-Verantwortlichen in europäischen KMU und Scale-ups, deren KI-Problem die Folien-Phase hinter sich hat. Sie haben einen Prototyp, der zum Produkt werden soll, eine Pipeline, die in Produktion zickt, oder eine Compliance-Deadline, die nicht reißen darf.
Ich bin Bhavesh Jain, Senior Data Scientist mit Sitz in Deutschland. Sechs Jahre Erfahrung im Aufbau echter Machine-Learning-Systeme. Hauptberuflich arbeite ich am Fraunhofer ISI am JIH Trend Radar. Daneben übernehme ich pro Jahr eine kleine Zahl unabhängiger Aufträge, ausschließlich Implementierung.
Die meisten Engagements fallen in eine dieser sechs Formen. Wenn Ihr Problem nicht passt, schreiben Sie einfach — ich sage Ihnen ehrlich, ob ich die richtige Person bin.
Senden Sie mir Ihre Systemdokumentation, Architektur-Diagramme und das Problem, das Sie lösen. Sie bekommen ein schriftliches Review zurück: was funktioniert, was riskant ist, was zuerst zu ändern ist. Asynchron, keine Meetings.
Vollständige Compliance-Bewertung nach dem EU AI Act. Risikoklassifizierung Ihrer KI-Systeme (hohes, begrenztes, minimales Risiko), Gap-Analyse zu Act-Anforderungen und priorisierter Sanierungsplan. Schriftliche Dokumentation (~30 Seiten), vollständig asynchron.
Ein kurzes Engagement, um eine Frage zu beantworten: Lohnt es sich, dieses KI-System zu reparieren, oder lohnt sich diese neue Idee? Sie bekommen einen Audit oder einen funktionierenden Prototyp, je nach Bedarf. Scope wird vor Kickoff festgelegt — Festpreis, keine Überraschungen.
Aufbau einer funktionierenden Evaluierungs-Harness für Ihr RAG-System auf Ihren echten Daten. Baseline-Metriken (Präzision, Recall, Halluzinationsrate), Fehler-Taxonomie über 100–200 Testfälle und eine reproduzierbare Test-Suite. Übergabe enthält lauffähigen Code und Dokumentation.
Vier bis acht Wochen fokussierte Implementierung. Ich entwerfe das System, schreibe den Code, richte das Monitoring ein und übergebe es funktionsfähig. Zwei Wochen Post-Launch-Support inklusive.
Quartals-Outcomes: Einstellung Ihres ML-Engineers, Deployment von 1–2 Produktionsmodellen, Aufbau einer Eval-Harness. Code-Review, Architekturentscheidungen, Anbieter-Bewertung. Ein Tag pro Woche, drei Monate Minimum.
Für alles andere — EU-AI-Act-Readiness, eine zweite Meinung zu einem Anbieter-Pitch, ein einmaliges Code-Review — fragen Sie einfach. Ich nenne Ihnen vor Beginn der Arbeit einen Festpreis oder Stundensatz.
Zwei Wochen. Deutscher Mittelstands-SaaS, ca. 80 Engineers. Ihre RAG-Support-Pipeline lieferte in Produktion korrekt klingende, aber falsche Antworten; das interne Team jagte die Ursache seit zwei Monaten.
Was ich tatsächlich getan habe: ein Evaluations-Set aus ihren echten Support-Tickets gebaut, eine Failure-Mode-Taxonomie über 200 Fälle laufen lassen, den Re-Ranker getauscht, die Chunking-Strategie auf ihre Domäne umgebaut. Der Eval-Harnisch ist heute der Standard für ihre anderen ML-Services. Auf Wunsch anonymisiert; vollständige Referenz im Gespräch verfügbar.
Eine kurze Liste von Dingen, die ich ablehne oder weiterempfehle, damit wir beide Zeit sparen:
Fünf Schritte. Keine Agentur-Schichten, keine Angebots-Templates.
Dreißig Minuten. Wir sprechen darüber, was Sie bauen, wo es klemmt und wie Erfolg aussehen würde. Kein Pitch, kein Nachfassen, sofern Sie nicht darum bitten.
Innerhalb von 48 Stunden nach dem Gespräch erhalten Sie einen schriftlichen Scope: was ich baue, was der Liefergegenstand ist, und einen Festpreis oder eine Stundenschätzung. Keine versteckten Stunden.
Wir richten einen geteilten Workspace ein (Notion, Linear oder Ihr Tool) sowie einen Slack-Channel. Ich schicke jede Woche ein kurzes schriftliches Update.
Ich schreibe den Code, richte die Evaluation ein und deploye. Sie sehen bei jedem Milestone eine funktionierende Demo — keine Überraschungen am Ende.
Schriftliche Dokumentation, eine Trainings-Session für Ihr Team und zwei Wochen Post-Launch-Fixes. Danach gehört das System Ihrem Team.
Bei einem kürzlichen Production-Sprint, Woche drei: Die Evaluation zeigte, dass Retrieval zufällig einen von drei Vektor-Indizes auswählte, statt den konfigurierten. Ein Code-Pfad, den seit Monaten niemand angefasst hatte. Wir haben es im Dienstags-Review gesehen, weil wir die Evaluation vor jeder Retrieval-Arbeit eingerichtet hatten — und die Metrik fiel über Nacht um 12 Punkte.
Hätten wir nach Eindrücken gearbeitet, wäre dieser Bug live gegangen. Wir hätten noch einen Monat damit verbracht, "warum funktioniert es manchmal" in Produktion zu jagen. Stattdessen haben wir pünktlich ausgeliefert, mit einer schriftlichen Notiz im Übergabedokument, was wir gefangen haben und wie.
So arbeite ich, ungefähr. Evaluation vor Code. Demos bei jedem Milestone, nicht erst am Ende. Schriftliche Updates, damit Sie Entscheidungen sehen, während sie passieren. Und wenn mein erster Plan den Kontakt mit Ihren Daten nicht überlebt, hören Sie das von mir, bevor eine Deadline reißt.
Discovery-Sprints haben festen Scope; wir einigen uns auf die Frage, die wir beantworten — die bewegt sich nicht. Bei Production-Sprints sind kleine Kurskorrekturen im Puffer enthalten. Alles Größere bekommt einen schriftlichen Change-Order mit fester Delta-Pauschale. Keine Überraschungsrechnungen.
Manchmal. Wenn Ihr Problem dringend und klein ist, kann ich einen Discovery-Sprint in die laufende Woche schieben. Größere Sprints werden um aktive Verpflichtungen herum geplant. Fragen Sie, dann sage ich ehrlich.
Ja. Eine Standard-gegenseitige NDA geht vor jedem Arbeitsbeginn raus. Bei Ihrem Master Services Agreement starte ich in der Regel von Ihrem Template und markiere, was für eine Ein-Personen-Operation nicht passt.
Das ist ein echtes Risiko, und wir besprechen es im Kennenlerngespräch. Wenn Ihre Engineers nicht die Kapazität haben, parallel auszuliefern, ist der Production-Sprint die falsche Form. Besserer Weg: Mit einem Discovery-Sprint starten, herausfinden, was Ihr Team wirklich braucht, dann einen kleineren Scope-Build planen.
Manchmal ist das die richtige Antwort, und Sie bekommen trotzdem den vollen Liefergegenstand: das Evaluations-Set, die schriftliche Begründung und eine Empfehlung, was stattdessen zu tun ist. Lieber spare ich Ihnen die nächsten 18.000 €, als einen Build zu pushen, der nicht ausgeliefert werden sollte.
Der schnellste Weg, um zu wissen, ob es passt, ist ein dreißigminütiges Kennenlerngespräch.