bewerb/gedaechtnis/inhalte.md

Inhaltliche Bausteine (geprüft)

Bewährte, faktisch korrekte Inhalte und Formulierungen zu Erfahrungen/Skills. Was hier steht, ist verifiziert richtig. Wird am Ende jeder Session aktualisiert.

Korrekte Fakten

• Standard-All-in-Stundensatz für Agenturprojekte: 93 € netto (per Nutzer-Entscheidung 2026-06-29 von 105 € gesenkt; Direktbeauftragung KMU: 120 € netto). Quelle: vorgaben/marketing.md §2. Im Anschreiben als Vorstellung formulieren (Verhandlungsbereitschaft, siehe stil.md).

• Englischer Lebenslauf vorhanden: Basisname CV_Thomas_Langer_PhD — bei englischen Bewerbungen anhängen. Format empfängerabhängig: Agentur .doc, Endkunde .pdf (siehe stil.md).

• Eine Sicherheitsüberprüfung SÜ2 dauert mindestens drei Monate, teils bis zu einem Jahr → Projekte mit SÜ/Sicherheitsüberprüfung fallen aus (in vorgaben/rahmenbedingungen.md als ❌ verankert).

• On-Prem-Infrastruktur (belegbar, nutzbar in KI-Bewerbungen): Das EspoCRM läuft in einem Podman-Pod-Container auf dem Server DesTEngSsv006, dem eigenen On-Premise-KI-Server (GPU-Inference). Auf demselben Server laufen auch die Claude-Code-Sessions. Der projekt-anlegen-Skill holt Projektausschreibungen automatisiert von Portalen (z. B. freelancermap), gliedert sie in Must/Nice/Misc, bewertet sie und trägt sie via REST-API ins CRM ein. Beleg für Agentic AI, MCP, Web-Datenextraktion und produktiv genutzte On-Premise-KI; auch als konkreter, authentischer Aufhänger im Anschreiben verwendbar.

• LangChain / Langflow / Langfuse (verifiziert vom Nutzer, S+): Thomas hat Langflow evaluiert (Projekt Kischdle); Langflow setzt auf LangChain auf und erweitert es um eine Low-Code-Oberfläche. Langflow und Langfuse laufen produktiv in Containern auf dem eigenen lokalen KI-Server (DesTEngSsv006). Damit sind LangChain (über Langflow) und Langfuse ehrliche Buzzword-Treffer für LLM-App-/Observability-Ausschreibungen. Nicht belegt: LangGraph (nicht behaupten). Nutzbar für LLM, RAG, Workflow-Automatisierung.

• SOLCOM GmbH war die vermittelnde Agentur bei ASMPT und Magna (vom Nutzer bestätigt, S+). Bei künftigen SOLCOM-Bewerbungen darf die frühere Zusammenarbeit offen als Vertrauensanker angesprochen werden (siehe Warm-Referencing in stil.md). Im Lebenslauf selbst ist die vermittelnde Agentur je Mandat nicht hinterlegt — solche Zuordnungen nur verwenden, wenn der Nutzer sie bestätigt.

• n8n-Praxis (verifiziert vom Nutzer, S+, über den Lebenslauf hinaus): n8n ist seit 2025 Teil des selbst betriebenen Server-Setups (eigene Linux-Server seit 2011). Konkrete, belegte n8n-Arbeiten: eigene Workflows entworfen und gewartet, inklusive Customizations in JavaScript, wo die Standard-Nodes nicht ausreichten; ein Telegram-AI-Agent mit Zugriff auf Google-Cloud-Daten; ein RAG-Workflow, in dem n8n die Daten-Chunks bildete, die Vektoren per OpenAI-Embedding-Modell erzeugte und in einer Vektordatenbank ablegte. Nutzbar als konkreter Beleg für Workflow-Automatisierung, n8n-Nodes/Debugging, REST/Webhooks/JSON-Integration und KI-Anbindung in Workflows.

• RPA-/Oberflächenautomatisierung ohne API (belegt, für RPA-/Automatisierungs-Rollen): Zwei konkrete, gleichwertige Belege, wenn das geforderte Kern-Tool (z. B. UiPath) selbst nicht belegt ist. (1) Web-Oberflächen: bei Lumiz die Bestellvorgänge in einem webbasierten Druckerei-Shop mit UI.Vision vollständig automatisiert (Datenübernahme, Auswahl der Bestelloptionen, Bezahlung, Hochladen der Druckdaten). (2) Desktop-Anwendungen: Steuerung von Desktop-Programmen ohne API über Oberflächenautomatisierung mit Python (PyAutoGUI). Beide decken „RPA / gleichwertige RPA-Plattformen" und „nicht-triviale Steuerung von Legacy-Anwendungen ohne Schnittstelle" ab; Web-Automation passt auf webbasierte Systeme/Ticketsysteme, Desktop-Automation auf Desktop-/ERP-Anwendungen (z. B. Oracle Forms). Zusätzlich Microsoft Power Automate Desktop im Vorfeld eines KI-Workshops (ASMPT) kurz als RPA-Plattform evaluiert (nur „evaluiert", keine Produktivpraxis). Nutzbar für Workflow-Automatisierung.

• Make.com (verifiziert vom Nutzer, S+): Make.com während der AI-Consultant-Ausbildung praktisch eingesetzt, wegen Limitierungen und Kosten Umstieg auf n8n; KI-Automatisierungstools werden in eigenen Arbeitsabläufen genutzt. „Sehr gute Make.com-Kenntnisse" darf als ✅ behauptet werden. Beleg für Workflow-Automatisierung (Make.com und n8n). Bei Make.com-/Automatisierungs-Rollen mit Coaching-Anteil zusätzlich der CRM-API-Workflow (projekt-anlegen/bewerbung, REST-API) als Praxisnachweis nutzen (siehe On-Prem-Bullet oben).

• CI/CD als Anwendererfahrung (Nutzer-Angabe, auteega): Thomas hat Anwender-Erfahrung mit CI/CD-Prozessen (Nutzer bestätigt). Darf als „mit CI/CD-Prozessen bin ich als Anwender vertraut" formuliert werden. Abgrenzung: kein produktiver Aufbau/Betrieb von CI/CD-Pipelines und kein produktiver MLOps-Betrieb behaupten (siehe „MLOps, CI/CD, Cloud-native" unter „Nicht zutreffend"). Nutzbar für Verifikation & Validierung, Produktiver KI-Betrieb.

• KI-/Dokumentenanalyse-Praxis (für Computer-Vision-/Document-AI-Bewerbungen): Seit 2025 Erstellung von KI-Lösungen; LLMs werden täglich für die Analyse und Auswertung von Dokumenten genutzt (gedeckt, konsistent mit „Agentic AI ist alltägliches Werkzeug"). Die Vision-Fähigkeiten mehrerer aktueller KI-Modelle wurden evaluiert (Niveau „ausprobiert/getestet", siehe Multimodale KI) — nur erwähnen, nicht anpreisen, keine Modellnamen nötig. Guter ehrlicher Aufhänger: KI-Vision „extrahiert Informationen aus Dokumenten besser als konventionelle OCR-Methoden" — nennt den ❌-Buzzword OCR als Vergleichsgegenstand, ohne eigene OCR-Erfahrung zu behaupten.

• Testautomatisierung in mehreren Positionen (belegt, für Test-/QA-Rollen): Test-Automatisierungen sind über mehrere Stationen belegt: ASMPT (Python PyAutoGUI), Magna (CANoe-basierte Tester-SW, CAPL), Kathrein.net.tech (HF-Test-Automatisierung mit Matlab und Ruby), Alcatel-Lucent (Matlab-Test-Automatisierung, automatisierte Blocking-Tests, Kalibrationsumgebung), zusätzlich Ubidyne und Siemens (eher „Tests" als reine Automatisierung). Die kombinierte Formulierung „Testautomatisierungen und Tests waren wesentlicher Teil meiner Aufgaben" deckt auch Stationen ab, wo der Schwerpunkt auf Tests (nicht Automatisierung) lag, ohne Falschaussage. Nutzbar für Verifikation & Validierung.

• „Backend- und Integrationstests" ehrlich verankern (nicht als reine SW-QA behaupten): Klassisches Software-Backend-Testing (APIs/DB/Microservices) ist nicht belegt. Der Ausschreibungs-Buzzword lässt sich aber ehrlich andocken an: Prüfung von Kommunikationsschnittstellen und Protokollen (Ethernet-Feldbus, Nachrichtenformate, Python-REST-Clients mit FastAPI) bis zur Integration kompletter Subsysteme (System Integration). So entsteht ein Buzzword-Treffer ohne Überdehnung. Formulierung: „Backend- und Integrationstests, von der Prüfung von Kommunikationsschnittstellen und Protokollen bis zur Integration kompletter Subsysteme, gehörten zu meinen Aufgaben."

• Claude Code als Buzzword-Treffer bei „Claude"/„KI-gestützte Softwareentwicklung": Nennt die Ausschreibung Claude und/oder KI-gestützte Softwareentwicklung, ist der Claude-Code-Bezug ein sauberer Agentur-Buzzword-Treffer (anders als sonst bei Produktnamen). Belegt: seit März 2026 intensiv/produktiv mit Claude Code für Softwareentwicklung, Tests und Automatisierungen (CV: „produktiver Einsatz im DesTEngS-Geschäftsbetrieb").

• Coding-KI-Tool-Stack als Eignungsbeleg (für AI-Advisor-/„AI for Software Development"-Rollen): Konkret belegt und nennbar: GitHub Copilot (VS Code), VS Codium mit Cline in Verbindung mit Gemini- und OpenAI-Modellen sowie Claude Code und Claude Cowork (produktiver Einsatz seit März 2026). Diese Breite ist ein ehrlicher Beleg für „Bewertung und Auswahl von AI-Tools" und „AI for Software Development". Formulierung: „die führenden Coding-KI-Werkzeuge praktisch evaluiert: …". Für AI for Testing: Testautomatisierung in mehreren Positionen belegt (siehe Test-Bullet) plus „generative KI gezielt für Tests und Qualitätssicherung" (CV: „Anwendung von KI bei … Tests"). Nutzbar für Agentic AI, LLM, Verifikation & Validierung.

• GitHub Copilot / Visual Studio / VS Code aus der ASMPT-Projektarbeit (Nutzer bestätigt, Akkodis): Über die allgemeine Kenntnisse-Nennung im CV hinaus behauptbar: GitHub Copilot, Visual Studio und VS Code sind aus der Projektarbeit bei ASMPT vertraut (SMT Solutions, System Integration; Python-/C++-Entwicklung). Der Nutzer hat den Satz nach ausdrücklichem Hinweis im Anschreiben belassen. Sauberer Eignungsbeleg für Ausschreibungen, die diese Entwicklungsumgebungen bzw. KI-Coding-Assistenten nennen. Nutzbar für Python, Agentic AI.

• Cloud- vs. On-Premise-KI abwägen (belegt): Lokale KI-Modelle auf eigener GPU-Hardware mit NVIDIA-Blackwell-Technologie betrieben (On-Premise belegt) und zugleich Cloud-LLMs produktiv genutzt → Aussage „Cloud- und On-Premise-Lösungen mit ihren jeweiligen Stärken, auch unter den Gesichtspunkten Governance, Datenschutz und Compliance, gegeneinander abwägen" ist gedeckt. „DSGVO-konforme KI-Anwendungen" (CV) stützt Datenschutz/Compliance/Governance. Nutzbar für On-Premise KI, LLM.

• Self-Hosted-Container korrekt benennen — „Private Cloud Services", nicht „Microservices" (Nutzer S+): Git, Nextcloud, EspoCRM usw. in Docker-/Podman-Containern sind mehrere eigenständige Anwendungen, nicht die Zerlegung einer App in unabhängig deploybare Dienste. Daher „Private Cloud Services" (deckt sich mit dem CV-Wortlaut „Self-Hosted Services in Docker-/Podman-Containern"), nicht „Microservices". Bewährte Formulierung: „Seit 2011 nutze ich Linux Root Server, auf denen auch meine Private Cloud Services in Docker- oder Podman-Containern laufen; beispielsweise läuft mein CRM in meiner lokalen Umgebung." Nutzbar für On-Premise KI, Container.

• Geforderte „Cloud-Lösungen" ohne Hyperscaler-Praxis in zwei ehrlichen Arten belegen (Nutzer-Wunsch, Atruvia): Verlangt die Ausschreibung „containergestützte und Cloud-Lösungen" und fehlt AWS/GCP/Azure-Erfahrung (Match-❔), lässt sich der Cloud-Teil ehrlich über zwei Arten abdecken, ohne einen Hyperscaler zu behaupten oder die Lücke zu erwähnen: (1) Private Cloud Services auf eigenen Linux Root Servern (Docker/Podman, siehe Bullet oben) und (2) Cloud-KI-Dienste in selbst erstellten Programmen konsumiert — über die Python Libraries von OpenAI und Anthropic, der Claude-Code-CRM-Skill nutzt Cloud-Modelle über deren API, der n8n-Telegram-Agent greift auf Cloud-Daten zu. Bewährte Rahmung: „Mit containergestützten und Cloud-Lösungen arbeite ich auf zwei Wegen …". Deckt den Buzzword-Treffer „Cloud-Lösungen" ohne Falschaussage. AWS/GCP/Azure bleiben unerwähnt (nicht belegt). Nutzbar für Container, On-Premise KI, Agentic AI.

• On-Premise-Modelle nicht nur LLMs (Nutzer S+): Auf dem eigenen KI-Server laufen außer LLMs auch ASR- und TTS-Modelle (Open Source). Daher beim Agentur-Empfänger der breitere Begriff „Open-Source-KI-Modelle" statt „Open-Source-LLMs", wenn die ganze On-Premise-Bandbreite gemeint ist. Nutzbar für On-Premise KI, Multimodale KI.

• CAD-Systeme und Engineering-/PLM-Landschaften ehrlich verankern (für KI-im-Engineering-/Konstruktions-Rollen): „Konstruktion / CAD (z. B. CATIA)" zielt auf mechanisches CAD, das nicht belegt ist (kein CATIA, kein Maschinenbau-CAD) → nicht behaupten. Ehrlich abgedeckt ist dagegen: jahrzehntelange intensive Arbeit mit CAD-/EDA-Entwicklungswerkzeugen (Keysight ADS, Ansys HFSS/SIwave, CST, PCB-Layout) sowie deren Auswahl und Evaluierung (Toshiba: „Evaluierung und Auswahl von HF-Entwicklungssoftware"). „Digitale Engineering-/PLM-Landschaften": belegt über PTC Integrity (Requirements/Tasks/Reviews/Defects bei Magna), Azure DevOps Server, Git/Subversion und Cloud-gestützte Kollaborationsdienste. Zulässige Formulierung: „mit CAD-Systemen jahrzehntelang gearbeitet, mehrfach ausgewählt und evaluiert; Engineering-Prozesse, Product-Lifecycle-Management-Systeme und digitale Kollaborationsdienste bestens vertraut" — ohne Toolnamen beim Agentur-Empfänger (Buzzword-Ebene CAD/PLM/Engineering-Prozesse genügt).

• ASMPT-KI-Workshop-Vorbereitung als Beleg für KI-Use-Case-Analyse in Engineering-Prozessen: Zur Vorbereitung des KI-Potenzialanalyse-Workshops bei ASMPT hat Thomas sich mit den Engineering-Entwicklungsprozessen befasst und herausgearbeitet, an welchen Stellen sich generative KI integrieren lässt. Sauberer Beleg für „Analyse und Bewertung von KI-Anwendungsfällen in Konstruktions-/Entwicklungsprozessen". Drei KI-Potenzialanalyse-Workshops durchgeführt (Kerngeschäft, siehe KI-Beratung & Potenzialanalyse).

• AI-Agenten-Orchestrierung (belegt, für Agentic-AI-/MCP-Rollen): „Mit verschiedenen AI Automation Tools AI-Agenten orchestriert, sie mit Tools ausgestattet und an Datenquellen angebunden" ist gedeckt (n8n-Telegram-Agent mit Google-Cloud-Datenzugriff, Make.com, Langflow-Evaluierung). Tool Use / Function Calling und Datenanbindung als alltägliches Werkzeug behauptbar. Nutzbar für Agentic AI, MCP, Workflow-Automatisierung.

• Teil-/Randanforderungen ehrlich als „Anwenderwissen" rahmen (statt überziehen oder verschweigen): Bei einer Must-/Nice-Anforderung, die nur auf Anwenderniveau belegt ist, offen so benennen, statt Praxis vorzutäuschen oder die Anforderung ganz zu ignorieren. Bewährt bei ICB (KI Engineer, Endkunde): relationale Datenbanken → „über verschiedene relationale Datenbanken habe ich Anwenderwissen"; Google Cloud → „Google Cloud Dienste kenne ich als Anwender" (gedeckt durch den n8n-Telegram-Agenten mit Google-Cloud-Datenzugriff). Wirkt souverän und ehrlich, deckt den Buzzword-Treffer, ohne eine Falschaussage. Azure bleibt unerwähnt (nicht belegt).

• Supervised Fine-Tuning end-to-end belegt (Detail, Nutzer S+, ICB): Über die reine SFT-Nennung hinaus behauptbar: eigene Trainingsdaten generiert, mit Supervised Fine Tuning ein OpenAI-Modell (gpt-4o-mini) modifiziert und zum Testen einen Chatbot mit diesem Modell online gestellt. Sauberer Beleg für „LLM-Fine-Tuning" inkl. Trainingsdaten-Erzeugung und Evaluierung. Nutzbar für LLM.

• RAG-Tätigkeiten (nicht -Produkt) benennbar (Präzisierung, ICB): Als Tätigkeiten behauptbar: „Inference- und Embedding-Modelle evaluiert, Chunks erstellt und in Vektordatenbanken geladen, die Qualität der semantischen Suche validiert" (gedeckt durch den n8n-RAG-Workflow, der Chunks bildet, Vektoren per OpenAI-Embedding erzeugt und in einer Vektordatenbank ablegt, plus die Kischdle-Modellevaluierung). Weiterhin keine fertige/produktive RAG-Lösung behaupten (siehe „Nicht zutreffend"). Nutzbar für RAG, Vektordatenbanken.

• Datenpipelines und Zeitreihenverarbeitung (belegt, für Data-/Backend-Plattform-Rollen): Ehrlich behauptbar als „Datenpipelines und die Verarbeitung von Zeitreihen in mehreren Projekten aufgebaut, etwa bei der Analyse und Konvertierung von Netzwerk- und Kommunikationsdaten" (gedeckt durch PyShark-Trace-Konvertierung, Pandas/NumPy-Datenanalyse, zeitbezogene Ethernet-/CAN-Verkehrsanalyse mit KPIs/Timing bei ASMPT). Buzzword-Treffer für „Datenpipelines", „Zeitreihenverarbeitung". Nutzbar für Python, System Integration.

• SQL nicht offensiv als Skill ausspielen (Nutzer-Signal, Drost Consulting): Obwohl SQL im CRM-Match als ✅ bestätigt wurde, hat der Nutzer SQL aus dem Bewerbungstext gestrichen. SQL daher nicht als aktiven Skill-/Buzzword-Claim in Anschreiben setzen, außer der Nutzer wünscht es ausdrücklich. REST APIs, Docker, Git bleiben unbedenklich.

• State-of-the-Art Coding-Agenten decken weniger geläufige Programmiersprachen ab (belegt, Fähigkeit): Python ist primäre Sprache; Rust, Go, Java, TypeScript u. a. werden mit Coding-Agenten effizient und auf hohem Qualitätsniveau bedient. Ehrliche Fähigkeitsaussage (TÜV-AI-Consultant, produktiver Coding-Agent-Einsatz seit März 2026), kein Referenzclaim. Formulierung siehe stil.md. Nutzbar für Agentic AI, Python.

• Angebotsausarbeitung und aktiver Verkauf (belegt, für Consultant-/Vertriebs-nahe Rollen): Fordert die Ausschreibung „Ausarbeitung maßgeschneiderter Angebote" und „aktiven Verkauf von Lösungen/Prototypen", ist das ehrlich über die Selbstständigkeit gedeckt: „Aus fünfzehn Jahren als selbstständiger Consultant bin ich es gewohnt, maßgeschneiderte Angebote auszuarbeiten, sie zu verkaufen und Projekte von der ersten Idee bis zur produktiven Umsetzung zu begleiten." Fähigkeits-/Erfahrungsaussage, kein Referenzclaim. Nutzbar für KI-Beratung & Potenzialanalyse.

• Server-Betrieb und Troubleshooting (belegt, für „Server-Management / Lifecycle / was tun, wenn ein Server crasht"): „Seit 2011 betreibe ich eigene Linux Root Server … Reverse Proxy, TLS, Backups und Monitoring ebenso wie Systemarchitektur, APIs und Server-Betrieb; fällt ein Dienst aus, übernehme ich die systematische Fehleranalyse eigenverantwortlich." Deckt Server-Management, Betrieb/Monitoring und eigenverantwortliches Troubleshooting ehrlich ab (CV: Eigenbetrieb Internet-Server seit 2011, Backups/Monitoring via Virtualmin). Guter Baustein für die oft geforderte Cloud-Infrastruktur/Server-Management-Zeile (die als ❔ im Match steht), ohne klassische Hyperscaler-Plattform zu behaupten. Nutzbar für On-Premise KI, Container, Produktiver KI-Betrieb.

Bewährte Bausteine

• Product-Lifecycle-Baustein: „In mehreren Positionen habe ich komplexe technische Systeme von Grund auf begleitet, vom Aufstellen der Anforderungen über Lösungskonzepte und Implementierung bis zu Verifikation, Deployment und geordnetem Wissenstransfer bei der Übergabe."
• Wissenstransfer an Kunden ist in jedem Projekt gelebte Selbstverständlichkeit: laufend über regelmäßige Update-Meetings und direkten Austausch während der Zusammenarbeit, nach Bedarf. Nicht auf die (kurzen) KI-Workshops/Schulungen verengen, das stellt es zu klein dar. Bewährter Satz (Doku-Variante, wenn die Rolle Dokumentation betont): „Wissenstransfer ist für mich gelebte Praxis: In allen bisherigen Projekten habe ich mein Wissen laufend in regelmäßigen Update-Meetings, je nach Bedarf im direkten Austausch mit den Experten und durch sorgfältige Dokumentation an die Teams meiner Kunden weitergegeben."
• Brücke IT ↔ Management (Baustein für BA-/Koordinations-/Schnittstellenrollen): „Durch meine technische Erfahrung von der Anforderungsaufnahme über Spezifikation und Software-Design bis zur System Integration begegne ich den Entwicklungsteams auf Augenhöhe. Zugleich kenne ich aus über vierzehn Jahren freiberuflicher Tätigkeit mit konsequenter Kundenorientierung und als Gruppenleiter mit Berichtslinie an die Entwicklungsleitung (VP Engineering) bei Ubidyne die Sprache und die Prioritäten des Managements." Als eigener Absatz ausspielen.
• „Technical Liaison"/Kundensupport-Anforderung ehrlich als Kommunikations-/Vermittlungskompetenz rahmen (Nutzer S+, INOVA): Eine Application-Engineer-typische Aufgabe wie „technical liaison / Betreuung internationaler (End-)Kunden" ist nicht belegt — Thomas war nie im herstellerseitigen FAE-/Endkunden-Support → nicht behaupten („technische Betreuung internationaler Kunden" vom Nutzer zu Recht kassiert). Ehrlich abgedeckt und die eigentlich geforderte Kernkompetenz ist das klare Vermitteln technischer Themen im internationalen Umfeld: gedeckt durch CV-Zusammenfassung „Kommunikations- und Präsentationsstärke auf allen Ebenen, von Fachteams bis Geschäftsführung", Englisch fließend sowie internationale Zusammenarbeit (Normierungsgremien OIF/MIPI, Toshiba, externe Entwicklungspartner). Bewährte Formulierung: „In der Zusammenarbeit mit Chip-Design-Teams und in der System Integration bin ich ebenso zu Hause; auch bin ich es gewohnt, technische Themen im internationalen Umfeld und auf Englisch zu diskutieren." Nutzbar für System Integration, Embedded & Kommunikationstechnik.
• Kischdle als Gründungsvorhaben mit Business-Analyse (Baustein für Consultant-/Business-nahe Rollen): Das On-Premise-KI-Konzept war kein Solo-Projekt, sondern ein Gründungsvorhaben mit Partnern (Thomas als Mit-Initiator mit technischer Verantwortung), geplant als Produkt für den Mittelstand. Neben der Technik (Machbarkeit geprüft, Inference- und Embedding-Modelle für eine RAG-Anwendung evaluiert) umfasste es die betriebswirtschaftliche Seite: Marktanalyse, Zielgruppendefinition, Abschätzung des adressierbaren Marktes. Bewährte Formulierung: „In einem früheren Gründungsvorhaben habe ich gemeinsam mit Partnern das Konzept eines On-Premise-KI-Systems mit RAG erarbeitet, geplant als Produkt für den Mittelstand. Als Mit-Initiator mit der technischen Verantwortung habe ich die Machbarkeit geprüft, eine Marktanalyse mit Zielgruppendefinition und Abschätzung des adressierbaren Marktes erstellt sowie Inference- und Embedding-Modelle für die RAG-Anwendung evaluiert." Bei Festanstellung „früheres" Gründungsvorhaben (siehe stil.md). Weiterhin kein produktiver RAG-Wirkbetrieb behaupten (siehe „Nicht zutreffend"). Nutzbar für KI-Beratung & Potenzialanalyse, On-Premise KI, RAG.

Belegte Branchen-/Domänen-Erfahrung

• HF-/Mikrowellen-Entwicklung als Kern-Baustein (belegt, für RF-/Hochfrequenz-Rollen): Durchgängig belegte Kernkompetenz: Ubidyne (Head of RF Integration, rund 240 Aufbauten DC–3,6 Gb/s, Multistandard-Transceiver-Module für aktive Antennen, Evaluierungs-/Applikationsboards für GaAs-/SiGe-/CMOS-ASICs), Siemens (RX-Frontend-Modul GSM-Basisstation von Architektur bis Fertigungseinführung, 10-GHz-VCO qualifiziert), Alcatel-Lucent (RX-Pfad mit LNAs/Filtern/Demodulator/ADC getestet und optimiert, HF-Frontend-Überarbeitung → 28 % Flächenreduktion), Infineon (Chip-PCB-Übergänge von 77-GHz-Radar-MMICs), FBH (MMIC-Sampling-Schaltungen, Harmonische bis 140 GHz). HF-Messtechnik sicher: Netzwerkanalysatoren bis 110 GHz, Sampling-/Realtime-Oszilloskope, S-Parameter on-wafer und koaxial. Nutzbar für Hochfrequenztechnik, System Integration, Verifikation & Validierung.
• „Erstellung flexibler Produktvarianten" richtig deuten (Nutzer S+, WORK Microwave): Gemeint ist nicht das separate Entwickeln vieler Einzelvarianten, sondern ein Produkt so zu entwerfen, dass es über kleine Bestückungs-/Konfigurationsvariationen mehrere Kundenanforderungen abdeckt (design-for-variant). Ehrlich belegt durch die Multistandard-Transceiver-Module (Ubidyne). Nutzbar für Hochfrequenztechnik, System Integration.
• Automotive belegt durch Magna Electronics (LIDAR Compute Module, ADAS) und Infineon (77 GHz ADAS Radar MMICs). Darf als „Automotive Bereich" benannt werden.
• Vector CANoe darf als ✅ namentlich genannt werden: bei Magna in der CANoe-basierten Tester-SW (CANoe GUI Design, CAPL) eingesetzt; bei ASMPT zusätzlich CANalyzer/CANape. Formulierung „Vector Tools wie CANoe" oder direkt „Vector CANoe" beides möglich. CAN-Bus breit belegt (ASMPT, Magna). Nicht belegt und daher nicht behaupten: UDS-Diagnosen, Fahrzeugnetzwerkmanagement, DOORS/Jama, Vector CANdela, Automotive SPICE, Gurt-/Rückhaltesysteme.
• Telekommunikation belegt durch Alcatel-Lucent (LTE), Ubidyne (aktive Antennen für Mobilfunk-Basisstationen), Siemens (GSM-Basisstationen).
• Startup-Erfahrung (zwei Startups, belegt): Ubidyne (ca. 60 Mitarbeiter) und Multilink Technology (bis ca. 360 Mitarbeiter weltweit). Nutzbar als authentischer Begeisterungs-/Kultur-Anker bei Arbeitgebern mit Startup-Spirit („großartige Erfahrungen in zwei Startups"). Ubidyne darf im Text ausdrücklich „Startup" genannt werden (z. B. „Beim Startup Ubidyne habe ich als Head of RF Integration …"), was den Führungs-Beleg zugleich als Startup-Anker doppelt nutzt. Startup-Reife als persönliche Lehre formulierbar (GovRadar, Startup + Public Sector): „Ich habe selbst erlebt, wie Startups mit exzellenter Technik, aber ohne echte Nachfrage gescheitert sind" — impliziert elegant Wertschätzung für gesicherte Nachfrage, ohne die eigenen Startups namentlich als Fehlschlag zu brandmarken.
• „15 Jahre als Consultant" (belegt): freiberuflicher Consultant / Inhaber DesTEngS seit Juli 2011 (2026 also rund 15 Jahre). Als persönliche, lockere Alternative zur „jahrzehntelangen Erfahrung" nutzbar (siehe stil.md).
• Führung/Management-Schnittstelle: Bei Ubidyne Gruppenleiter (bis zu 10 Mitarbeiter) mit Berichtslinie an die Entwicklungsleitung (VP Engineering) — vom Nutzer bestätigt, als Beleg für „Management-Sprache verstehen" nutzbar.
  • Fachübergreifende Zusammenarbeit bei Ubidyne (verifiziert vom Nutzer, S+, Atruvia): Die RF-Integration-Gruppe arbeitete eng mit dem System Engineering, zwei ASIC-Design-Teams und einem Power-Amplifier-Design-Team in den USA zusammen. Damit lässt sich die eine echte Leitungsposition ausdrücklich als fachübergreifend benennen und trifft den Must-have „Leitung fachübergreifender Projekte" sauber. Nutzbar für Projektmanagement, Systems Engineering.
  • Ehrlichkeitsgrenzen Führung/Fine-Tuning (Nutzer S+, Atruvia): (1) Nur EINE echte Leitungsposition (Ubidyne) → nicht „fachübergreifende Projekte mehrfach geleitet" behaupten; „In fachübergreifenden Projekten habe ich oft gearbeitet" plus der eine Ubidyne-Führungsbeleg ist die Grenze. (2) Keine Generierung von Evaluierungsdatensätzen behaupten — belegt ist nur die Erzeugung eigener Trainingsdaten fürs Supervised Fine Tuning (nicht Eval-Datensätze).
• Industrieelektronik belegt durch ASMPT SMT Solutions (industrielle Bestückungsmaschinen).
• Serializer-/Deserializer-Systeme (SerDes) seit 2000 belegt: Multilink Technology (Backplane-Entzerrer-ICs/Demultiplexer ab Dez. 2000), Toshiba (Transceiver-ICs bis 11 Gb/s, MIPI D-PHY), Magna (GMSL-Pfad eines Kameramoduls, Signalintegrität). Formulierung „seit 2000 immer wieder mit Serializer-/Deserializer-Systemen beschäftigt" ist gedeckt.
• Display-/Video-Technologie: konkreter Beleg nur der GMSL-Pfad eines Kameramoduls (Magna, EM-Feldsimulation/Signalintegrität). Es gibt keine Erfahrung in Integration/Konfiguration von Display-ICs (Deserializer, TDDI-Controller) → nicht behaupten, nur als „mit GMSL/Videoschnittstellen gearbeitet" auf Signalintegritäts-/Bring-up-Niveau benennen.
• Kein Beleg für sicherheits-/missionskritische Systeme nach Safety-Prozessen (ISO 26262, DO-178) und keine INCOSE-/IREB-Zertifizierung → nicht behaupten.

Nicht zutreffend / nicht behaupten

• Nicht behaupten, täglich/laufend an einer produktionsreifen Agentic-AI-Plattform oder „der ersten produktionsreifen Plattform" zu arbeiten.
• On-Premise-KI mit RAG (Projekt „Kischdle") ist Proof-of-Concept-/Evaluierungsniveau, kein produktiver ML-Wirkbetrieb → kein „tiefgehendes Production-ML/MLOps" behaupten. Präzisierung (Nutzer S+): Beim RAG selbst wurden nur die Komponenten Embedding-Modell und LLMs evaluiert; eine vollständige RAG-Implementierung kam nicht mehr zustande → keine fertige RAG-Lösung/-Implementierung behaupten, nur die Evaluierung von Inference- und Embedding-Modellen für eine RAG-Anwendung.
• KI-Potenzialanalyse-Workshops — keine Umsetzungs-Roadmap behaupten (Nutzer S+): In keinem der drei durchgeführten Workshops wurde eine Umsetzungs-/Implementierungs-Roadmap erstellt (die Unternehmen wollten das nicht). Belegbar und behauptbar ist nur: konkrete KI-Anwendungsfälle identifiziert und bewertet. Die Fähigkeit, KI-Roadmaps zu erarbeiten, darf als Kompetenz/Fähigkeit formuliert werden (z. B. „kann ich … gemeinsam mit Stakeholdern erarbeiten"), nicht als Referenz/erledigte Arbeit.
• Keine Kafka-Praxiserfahrung behaupten (nur übertragbares Verständnis ereignisgetriebener Architekturen vorhanden).
• Scrum/agile Vorgehensweisen nur einmal gelebt (Alcatel-Lucent, „Agile Design mit Scrum") → nicht als breite Kompetenz anpreisen; SAFe gar nicht behaupten.
• BPMN, Use Cases, User Stories nicht wörtlich behaupten (im Lebenslauf nicht belegt). Stattdessen „Modellierung fachlicher Abläufe" o. Ä. verwenden.
• Computer Vision / Bildverarbeitung: Nur Evaluierung/Einsatz multimodaler Vision-Language-Modelle (VLMs) belegt (Multimodale KI), keine klassische Computer Vision / Bildverarbeitung (OpenCV-Pipelines, Feature-Detection, Objektdetektoren, Training) → nicht als fundierte CV-Kompetenz anpreisen. Saubere Abstufung (Nutzer S+, Fratch ADAS): „Computer Vision" nur als Konzept/Fachgebiet behaupten („mit Computer-Vision-Konzepten vertraut", „Konzepte von Computer Vision geläufig" — deckt Ausschreibungs-Buzzwords wie „computer vision conceptual understanding") oder als Vergleichsgegenstand (OCR-Trick). Eigene Praxis nur über „Vision-Language-Modelle"/„multimodale KI" formulieren („mit VLMs praktisch gearbeitet", belegt durch Qwen3-VL-Evaluierung und tägliche LLM-Dokumentenauswertung). Verboten: „praktische Erfahrung/Expertise mit Computer Vision" (suggeriert Bau eigener CV-Systeme). Faustregel: eigenes Tun ⇒ VLM/multimodale KI; nur Verständnis/Vergleich ⇒ Computer Vision.
• OCR-Technologien / Document-AI: keine Praxis (Paperless-ngx wird betrieben, aber kein OCR-Entwicklungsnachweis) → nicht behaupten.
• Lumiz-Bestellautomatisierung ist KEIN KI-Beleg (Nutzer S+): Die Automatisierung der Druckerei-Bestellungen bei Lumiz war Web-/Oberflächenautomatisierung mit UI.Vision, keine KI-Glanzleistung. Nicht als operativer/produktiver KI-Implementierungs-Beleg oder Marketing-Highlight verwenden; taugt nur als RPA-/Oberflächenautomatisierungs-Beleg (siehe RPA-Bullet oben). Nutzbar für Workflow-Automatisierung, nicht für KI-Kernrollen.
• MLOps, CI/CD, Cloud-native: kein belegter produktiver MLOps-/Cloud-native-Betrieb (Fokus On-Premise/Self-Hosted; Azure DevOps Server = ALM, kein Cloud-native-Beleg) → keinen produktiven MLOps-/Pipeline-Betrieb behaupten. Ausnahme CI/CD auf Anwenderebene: ist laut Nutzer belegt (siehe „CI/CD als Anwendererfahrung" oben) und darf als „mit CI/CD-Prozessen als Anwender vertraut" formuliert werden; MLOps/LLMOps/DevOps nur als „Prinzipien kenne ich".
• Wissensdatenbanken/Knowledge-Base-Verarbeitung nicht als eigene Praxis behaupten (Nutzer S+, auteega): Belegt ist die Verarbeitung unstrukturierter Daten aus Dokumenten (RAG-Chunking, tägliche LLM-Dokumentenauswertung). Die Verarbeitung von Wissensdatenbanken trifft laut Nutzer nicht zu → weglassen, auch nicht als Buzzword-Treffer erzwingen (Ausschreibungswortlaut „Dokumente, Mails, Wissensdatenbanken" nur mit „Dokumenten" bedienen).
• Kein produktiver Ausroll von AI-Agents in Kundenprojekten (Nutzer S+, Rigeto): Es gab noch kein Projekt, in dem Thomas AI-Agents produktiv in den Kundeneinsatz gebracht hat. Die Posting-Säule „PoC bis produktiver Einsatz von Agenten/ KI-Workflows inkl. Adoption/QS/Monitoring" nicht als geleistete Referenz behaupten. Belegt und behauptbar bleibt der eigene produktiv laufende Claude-Code-CRM-Skill (Geschäftsbetrieb) sowie die Fähigkeit, Lösungen bis zur Produktivsetzung zu führen; die kundenseitige Rollout-Erfahrung nicht überziehen. Nutzbar für Agentic AI, Produktiver KI-Betrieb.
• Keine „durchgängige" KI-Dokumentation und kein Aufbau von Doku-Standards/-Frameworks behaupten (Nutzer S+, 1st solution consulting): „Technische Dokumentation durchgängig mit generativer KI erstellt und dabei einheitliche Standards und Strukturen aufgebaut" ist nicht belegt und wurde vom Nutzer als Falschaussage kassiert. Belegt und behauptbar bleibt nur: KI-gestützte Dokumentation in einzelnen Projekten (CV: ASMPT Transformationslogik, „KI-gestützte Dokumentationen und Illustrationen"). Kein flächendeckender „Documentation-Framework/Governance-Aufbau". Nutzbar für Technische Dokumentation & Wissensmanagement.
• RAG-Overreach vermeiden (Nutzer S+, 1st solution consulting): „Unternehmensdaten in semantisch durchsuchbare Form gebracht" überzieht die belegten RAG-Tätigkeiten und ist nicht behauptbar. Grenze bleibt: „RAG-Systeme konzipiert, Embedding-Modelle und Vektordatenbanken evaluiert, die Qualität der semantischen Suche validiert" (plus Chunks erstellt/geladen, siehe RAG-Tätigkeiten-Bullet oben). Nutzbar für RAG.
• APIs von Standard-Unternehmenssystemen (SharePoint, Jira, Confluence, Azure OpenAI o. Ä.): keine belegte API-Praxis mit diesen Systemen → keine Referenzprojekt-/Erfahrungs-Behauptung. Zulässig ist nur die Fähigkeits-/Umsetzbarkeitsaussage, dass sich solche Schnittstellen KI-gestützt schnell entwickeln bzw. anbinden lassen (Formulierung „so lassen sich Schnittstellen zu APIs von … entwickeln", „gehe ich davon aus, dass sich … integrieren lässt"). Stützt einen Buzzword-Treffer auf die Kundensysteme, ohne Falschaussage. (Effection Network, AI / MCP Engineer.)