Freelancer · Freiburg im Breisgau · Softwareentwickler seit 2009

Software & KI-Lösungen
die wirklich
funktionieren.

Direkt. Persönlich. Ohne Zwischenhändler.

Sie sprechen nicht mit einem Vertriebsmitarbeiter - Sie sprechen direkt mit mir. Als erfahrener Softwareentwickler, KI-Spezialist und ehemaliger Engineering Manager bringe ich über  Jahre Praxiserfahrung in Ihr Projekt ein. Vor Ort als Softwareentwickler in Freiburg und remote in der gesamten DACH-Region.

 Jahre
Praxiserfahrung
seit 2009
direkt 1:1
Persönlicher
Ansprechpartner
Delphi / Pascal
Kernsprache &
Spezialkompetenz
24 h
Reaktions­zeit
Andreas Frank - Softwareentwickler und KI-Spezialist Freiburg
Andreas Frank Softwareentwickler & KI-Spezialist
Freiburg im Breisgau
Verfügbar für Projekte

Was mich von IT-Agenturen unterscheidet: Kein Projektmanager, kein Account Manager - ich entwickle Ihre Lösung persönlich, von der ersten Zeile Code bis zur Übergabe. Das spart Zeit, Kosten und Missverständnisse.

Stack: Delphi / Pascal C#PythonSQL REST APIsOpenAI / LLMs AndroidJava / Kotlin PHPNext.jsAzure

Mein Kerngebiet

KI-Integration - mein größtes Alleinstellungsmerkmal

Während andere IT-Dienstleister KI als Buzzword verwenden, implementiere ich sie konkret, messbar und auf Ihre Geschäftsprozesse zugeschnitten - zertifiziert und praxiserprobt.

KI-Lösungen für Unternehmen & KMU in Freiburg und im deutschsprachigen Raum

Ich entwickle KI-Agenten, integriere Large Language Models (LLMs wie GPT-4) und baue intelligente Analyse-Werkzeuge zur Automatisierung Ihrer Geschäftsprozesse. Zertifiziert durch ein 25,5-stündiges Intensivstudium in Deep Learning & Neuronalen Netzen (Udemy, Februar 2025). Mein Fokus: Datenanalyse, Sprachverarbeitung (NLP) und Prozessautomatisierung.

KI-AgentenLLM-Integration (GPT-4 / lokal) ProzessautomatisierungDatenanalyse & ML NLP / ChatbotsDeep Learning

Spezialkompetenz: Modernisierung von Legacy-Systemen (Delphi / C#)

Delphi / PascalC#Code-MigrationSystemintegration

Windows- & Mobilentwicklung

Delphi · Android

Native Apps für Windows und Android - inklusive Modernisierung bestehender Lösungen.

DelphiAndroidJava / Kotlin

Webentwicklung & SEO

Next.js · PHP

Responsive Webseiten mit technischem SEO und Core Web Vitals-Optimierung.

Next.jsPHPJavaScriptWordPress

Schnittstellen & Datenbanken

SQL · REST

Stabile APIs und Datenbankarchitekturen - auch für Legacy-Umgebungen.

REST/SOAPMSSQLMySQLSybase

IT-Dienstleistungen & Beratung

Beratung

Beratung, Schulungen und Digitalisierung - mit dem Weitblick eines Engineering Managers.

IT-BeratungSchulungDigitalisierung

Referenzprojekte

Ausgewählte Projekte

Vier aktuelle Beispiele aus der Praxis - anonymisiert, aber real.

Webentwicklung · Bildung

Webbasierte Lernplattform für ein Freiburger Bildungsunternehmen

Full-Stack-Entwicklung einer interaktiven Lernplattform: PHP-Backend, Next.js-Frontend, containerisiert mit Docker, inklusive automatisierter Testsuite. Lernkarten-Algorithmen, Suchfunktionen, individuelle Auswertungen. Projektlaufzeit: 2,5 Jahre, agile Umsetzung in Sprints.

PHPNext.jsDockerTestsuiteLernplattform
CRM & Datenbank · Infotainment

CRM-Erweiterung & Datenbankauswertungen für einen Event-Dienstleister

Erweiterung und Anpassung eines Combit CRM-Systems sowie Entwicklung datenbankgestützter Auswertungen und individueller Berichte mit Combit List&Label zur Ermittlung betrieblicher Kennzahlen für die Geschäftsführung.

Combit CRMCombit List&LabelSQLDatenbankauswertung
Webentwicklung & SEO · Solartech

SEO-optimierte Unternehmenswebseite für ein Solartech-Unternehmen

Konzeption, Entwicklung und Suchmaschinenoptimierung einer professionellen Unternehmenswebseite inkl. technischem SEO, Schema-Markup und Core Web Vitals-Optimierung - mit dem Ziel maximaler organischer Sichtbarkeit in der Region.

WebentwicklungSEOSchema-MarkupCore Web Vitals

Alle Referenzen ansehen →

Ablauf

Von der Idee zur fertigen Lösung

Klar strukturiert, transparent kommuniziert - Sie wissen jederzeit, wo Ihr Projekt steht.

01
Erstgespräch
Kostenlos & unverbindlich. Ehrliche Einschätzung - ohne Verkaufsdruck.
02
Angebot
Transparentes Festpreis- oder Stundenbasiertes Angebot - keine Überraschungen.
03
Entwicklung
Agil, mit regelmäßigem Feedback und direktem Kontakt - immer.
04
Übergabe & Support
Mit vollständiger Dokumentation und optionalem Support-Vertrag.

Lassen Sie uns Ihr Projekt besprechen.

Kostenloses Erstgespräch - direkt mit mir, kein Umweg.

Jetzt Kontakt aufnehmen →

Leistungen

Individuelle Softwarelösungen
& IT-Dienstleistungen

Jede Lösung wird von mir persönlich entwickelt - keine Weitergabe an Subunternehmer, keine anonymen Teams.

KI-Integration & Automatisierung

Mein USP

Echte KI-Lösungen für den Mittelstand - kein Buzzword-Marketing. Zertifiziert in Deep Learning & Neuronalen Netzen (Udemy, Feb. 2025, 25,5 Std.). Kein Einsatz für Grafik- oder Video-KI - mein Fokus liegt auf messbaren Geschäftsergebnissen.

  • KI-Agenten und vollautomatisierte Workflows
  • LLM-Integration (OpenAI GPT-4, lokale Modelle)
  • KI-Chatbots für Webseiten & Kundendienst
  • Datenanalyse, ML-Auswertungen & Vorhersagemodelle
  • Natural Language Processing (NLP)
  • Automatisierung von Ausschreibungs- & Geschäftsprozessen

Legacy-Modernisierung (Delphi / C#)

Spezialkompetenz

  • Migration Delphi 7 / Rio auf modernes .NET / C#
  • Code-Übernahme von C++, Visual Basic nach Delphi
  • Modernisierung und Erweiterung bestehender Windows-Apps
  • REST/SOAP-Schnittstellen für Legacy-Systeme nachrüsten
  • Integration von Altanwendungen in neue Systemlandschaften

Windows- & Mobilentwicklung

Delphi · Android

Native Anwendungen für Windows und Android - von der Neuentwicklung bis zur Modernisierung bestehender Delphi-Systeme.

  • Windows Desktop-Apps (Delphi, C#, WinForms)
  • Mobile Apps für Android (nativ, Java / Kotlin)
  • Modernisierung und Erweiterung bestehender Delphi-Anwendungen
  • Business-Prozessoptimierung durch maßgeschneiderte Software

Webentwicklung & SEO

Next.js · PHP

Responsive Webseiten und Webanwendungen mit technischem SEO, strukturierten Daten und Core Web Vitals-Optimierung.

  • Responsive Webdesign mit Next.js und PHP
  • JavaScript-Frontends & moderne Web-Apps
  • WordPress- und Joomla-Entwicklung & Wartung
  • Technisches SEO, Schema-Markup & Core Web Vitals
  • E-Commerce-Lösungen & Shop-Systeme

Schnittstellen & Datenbanken

SQL · REST

Stabile, dokumentierte APIs und effiziente Datenbankarchitekturen - auch für komplexe Legacy-Umgebungen.

  • REST- und SOAP-API-Entwicklung & Integration
  • Nahtlose Systemanbindung & Datenaustausch
  • Datenbankmodellierung: MSSQL, MySQL, Sybase, PostgreSQL
  • Performance-Analyse & Datenbankoptimierung
  • Individuelle Berichte, Auswertungen & Kennzahlen

IT-Dienstleistungen & Beratung

Beratung

Ganzheitliche IT-Beratung, Schulungen und Digitalisierung Ihrer Geschäftsprozesse - mit dem strategischen Weitblick eines erfahrenen Engineering Managers.

  • Umfassende IT-Beratung & Konzeption
  • Installation & Einrichtung von Branchensoftware
  • Systempflege, Wartung & Support
  • Schulungen für Mitarbeiter & Teams
  • Digitalisierung analoger Geschäftsprozesse

Preise

Faire, transparente Angebote

Individuelle Angebote auf Basis Ihrer Anforderungen. Branchenübliche Stundensätze, klar kalkuliert, keine versteckten Kosten.

Stundenbasiert

Ideal für Wartung, Beratung, Schulungen und kleinere Erweiterungen. Abrechnung nach tatsächlichem Aufwand - transparent und nachvollziehbar.

EMPFOHLEN

Festpreis-Projekt

Klares Budget, definierter Umfang - volle Planungssicherheit vom ersten Tag. Für Projekte mit klar definierten Anforderungen die beste Wahl.

Retainer / Support

Monatliche Zusammenarbeit für laufende Entwicklung, regelmäßige Wartung oder kontinuierliche IT-Beratung. Planbare Kosten, verlässliche Unterstützung.

Bereit für Ihr Projekt?

Unverbindliches Erstgespräch - direkt erreichbar.

Anfrage senden →

Referenzprojekte

Ausgewählte Projekte

Einblicke in abgeschlossene und laufende Projekte - anonymisiert, aber aus der realen Praxis.

Webentwicklung · Bildung · Freiburg

Webbasierte Lernplattform für ein Bildungsunternehmen

Full-Stack-Entwicklung einer interaktiven, webbasierten Lernplattform für den gymnasialen Nachhilfebereich. PHP-Backend mit REST API, Next.js-Frontend, containerisierter Betrieb via Docker und automatisierter Testsuite zur Qualitätssicherung. Kernaufgaben: Konzeption der Datenbankstrukturen, Implementierung adaptiver Lernkarten-Algorithmen, intelligente Suchfunktionen und individuelle Auswertungsstatistiken. Projektlaufzeit: 2,5 Jahre in agilen Sprints.

PHPNext.jsDockerTestsuiteLernplattformSQLREST API
CRM & Datenbank · Infotainment · Ruhrgebiet

CRM-Erweiterung & Datenbankauswertungen für einen Event-Dienstleister

Gezielte Erweiterung und Anpassung eines Combit CRM-Systems für einen überregional tätigen Event- und Infotainment-Dienstleister. Entwicklung datenbankgestützter Auswertungen und individueller Berichte mit Combit List&Label zur Ermittlung betrieblicher Kennzahlen für die Geschäftsführung. Ergebnis: deutlich schnellere Auswertungsprozesse und transparentere Entscheidungsgrundlagen.

Combit CRMCombit List&LabelSQLDatenbankauswertungKennzahlen
Webentwicklung & SEO · Solartech · Region Freiburg

SEO-optimierte Unternehmenswebseite für ein Solartech-Unternehmen

Konzeption, Entwicklung und vollständige Suchmaschinenoptimierung einer professionellen Unternehmenswebseite für einen regionalen Anbieter im Bereich Solartechnik. Leistungsumfang: technisches SEO, strukturierte Daten (Schema-Markup), Core Web Vitals-Optimierung, responsives Design und lokale SEO-Strategie - mit dem Ziel maximaler organischer Sichtbarkeit in der Region Freiburg und Südbaden.

WebentwicklungTechnisches SEOSchema-MarkupCore Web VitalsLokales SEO
IT-Beratung & Umsetzung · Medizin

IT-Beratung & technische Umsetzung für Facharztpraxen

Umfassende IT-Beratung und technische Umsetzung für mehrere Facharztpraxen: Analyse bestehender IT-Infrastrukturen, Empfehlung und Implementierung geeigneter Softwarelösungen, Optimierung von Praxisabläufen durch digitale Werkzeuge sowie Beratung zu Datenschutz- und Sicherheitsanforderungen im medizinischen Umfeld. Ergebnis: effizientere Praxisabläufe und erhöhte IT-Sicherheit bei gleichzeitiger DSGVO-Konformität.

IT-BeratungPraxissoftwareDSGVOIT-InfrastrukturDigitalisierung

Ihr Projekt könnte das nächste sein.

Lassen Sie uns in einem kostenlosen Erstgespräch herausfinden, wie ich Ihnen helfen kann.

Jetzt anfragen →

Blog & Wissen

Praxiswissen für den Mittelstand

Einblicke in KI-Integration, Legacy-Modernisierung und Softwareentwicklung - aus der täglichen Praxis, verständlich erklärt.

KI-Integration

KI ohne Cloud: Wann sich lokale Sprachmodelle im Mittelstand wirklich lohnen

85 Prozent der deutschen Unternehmen halten sich für zu abhängig von US-Cloud-Anbietern. Open-Source-Modelle auf eigener Hardware sind 2026 eine reale Alternative, haben aber klare Grenzen. Was sich rechnet und was nicht.

10. Juli 2026 · 8 Min.Lesen →

Digitalisierung

E-Rechnungspflicht ab 2027: Warum 2026 das entscheidende Jahr für Ihre Rechnungsprozesse ist

Am 31. Dezember 2026 endet die Übergangsfrist. Danach müssen die meisten Unternehmen strukturierte E-Rechnungen ausstellen. Was XRechnung und ZUGFeRD unterscheidet und warum alte ERP-Systeme jetzt zum Problem werden.

9. Juli 2026 · 7 Min.Lesen →

Webentwicklung & Recht

BFSG-Abmahnwelle 2026: Ist Ihre Website barrierefrei genug?

Seit Ende 2025 steigen die Abmahnungen wegen fehlender Barrierefreiheit deutlich. Die häufigsten Mängel sind rein technischer Natur und lassen sich systematisch beheben. Was Website-Betreiber jetzt prüfen sollten.

8. Juli 2026 · 6 Min.Lesen →

Recht & Compliance

Digital Omnibus: Die EU verschiebt zentrale AI-Act-Fristen. Was jetzt wirklich gilt

Ende Juni 2026 hat die EU zentrale Pflichten des AI Act verschoben. Hochrisiko-Anforderungen greifen erst Ende 2027. Welche Fristen bleiben, welche wandern und warum Abwarten trotzdem die falsche Strategie ist.

7. Juli 2026 · 7 Min.Lesen →

Recht & Compliance

EU Data Act: Ab September 2026 müssen vernetzte Produkte ihre Daten herausgeben

Ab dem 12. September 2026 müssen vernetzte Produkte Nutzerdaten maschinenlesbar bereitstellen. Was das technisch bedeutet, wen es trifft und warum Datenexport-Schnittstellen jetzt auf die Agenda gehören.

6. Juli 2026 · 7 Min.Lesen →

IT-Sicherheit & Compliance

Cyber Resilience Act: Warum die Meldepflichten ab September 2026 auch kleine Softwarehersteller treffen

Am 11. September 2026 startet die erste Stufe des Cyber Resilience Act. Aktiv ausgenutzte Schwachstellen müssen dann binnen 24 Stunden gemeldet werden. Das betrifft auch kleine Hersteller und alte Bestandsprodukte.

4. Juli 2026 · 7 Min.Lesen →

Recht & Compliance

EU AI Act: Transparenzpflichten für KI-Systeme und wie Sie sie umsetzen

Chatbots, KI-generierte Inhalte und Deepfakes müssen gekennzeichnet werden, nach dem Digital Omnibus mit angepasstem Zeitplan. Was zu tun ist und wie die Umsetzung in der Praxis aussieht.

5. Juli 2026 · 7 Min.Lesen →

IT-Sicherheit & Compliance

NIS2-Richtlinie 2026: Security by Design wird Pflicht für Software-Lieferanten

NIS2 ist seit Dezember 2025 deutsches Recht. Was das für Entwickler und Software-Zulieferer bedeutet, von den Lieferkettenpflichten über die Management-Haftung bis zur praktischen Umsetzung.

3. Juli 2026 · 7 Min.Lesen →

Softwareentwicklung

Green IT 2026: Nachhaltige Softwareentwicklung spart Kosten und erfüllt neue EU-Standards

ISO 20125 und neue Rechenzentrumsregeln ab Juli 2026 machen Energieeffizienz zur Pflicht. Wie Green Coding Cloud-Ausgaben um bis zu 40 % senkt und was Entwickler konkret umstellen müssen.

1. Juli 2026 · 6 Min.Lesen →

KI-Integration

Agentic AI für den Mittelstand: Wie autonome KI-Agenten Geschäftsprozesse wirklich verändern

Der Sprung vom Chatbot zum autonomen Agenten ist vollzogen. Was Agentic AI heute im Mittelstand leistet und was nicht, von der Rechnungsverarbeitung bis zur Angebotserstellung.

30. Juni 2026 · 7 Min.Lesen →

Softwareentwicklung

API-First Architektur 2026: Warum skalierbare Software ohne saubere Schnittstellen scheitert

API-First ist 2026 Standard und kein Trend mehr. Wie der Ansatz Entwicklungszeiten verkürzt, die KI-Integration vereinfacht und warum Deutschland auf ein föderales API-Plattform-Konzept setzt.

28. Juni 2026 · 6 Min.Lesen →

DevOps & Infrastruktur

Observability statt Monitoring: Wie KI-gestütztes System-Debugging die DevOps-Praxis verändert

Monitoring sagt Ihnen, dass etwas kaputt ist. Observability sagt Ihnen, warum. Wie KI-gestützte Observability-Tools für Kubernetes und Microservices die Mean Time to Resolution dramatisch senken.

27. Juni 2026 · 6 Min.Lesen →

KI-Integration

MCP: Das Model Context Protocol und warum es KI-Integration grundlegend verändert

Anthropics Model Context Protocol standardisiert die Anbindung von Tools an KI-Modelle. Was das für Entwickler bedeutet - und wie MCP die Brücke zwischen KI und bestehenden Unternehmenssystemen schlägt.

Juni 2026 · 6 Min.Lesen →

Softwareentwicklung

Vibe Coding in der Praxis: Was KI-gestützte Entwicklung für professionelle Software wirklich leistet

Mit einem Prompt zur fertigen Anwendung - das versprechen KI-Coding-Tools. Was dahinter steckt, wo die Grenzen liegen und warum professionelle Entwicklung trotzdem unverzichtbar bleibt.

Mai 2026 · 6 Min.Lesen →

KI-Integration

Claude Fable 5 wird abgekündigt: Was Entwickler bei KI-Modell-Migrationen beachten müssen

Anthropic kündigt die Abschaltung von Claude Fable 5 an. Wie schützt man Anwendungen vor Modell-Deprecations - und was ist bei einer Migration konkret zu beachten?

Mai 2026 · 7 Min.Lesen →

KI-Integration

Autonome KI-Agenten: Was sie können, was sie nicht können und wann sie sich lohnen

KI-Agenten erledigen Aufgaben selbstständig - von der Webrecherche bis zur E-Mail-Beantwortung. Was dahinter steckt, wo die Grenzen liegen und für welche Unternehmensprozesse sich der Einsatz heute wirklich rechnet.

April 2026 · 7 Min.Lesen →

IT-Sicherheit & Datenschutz

DSGVO und KI-Tools: Was Unternehmen bei der Integration von Sprachmodellen beachten müssen

ChatGPT, Copilot, Claude - KI-Assistenten sind produktiv, aber datenschutzrechtlich heikel. Welche Risiken bei der Verarbeitung personenbezogener Daten entstehen und wie man sie sauber löst.

April 2026 · 6 Min.Lesen →

Webentwicklung & SEO

SEO 2026: Was sich geändert hat und welche technischen Faktoren heute wirklich zählen

Google bewertet Websites anders als noch vor zwei Jahren. KI-gestützte Suchergebnisse, INP als neuer Core-Web-Vital und stärkere Nutzersignale verändern die Spielregeln - was Sie jetzt anpassen sollten.

März 2026 · 7 Min.Lesen →

Softwareentwicklung

Schnittstellen & APIs: Warum saubere Integration über den Erfolg von Software entscheidet

Moderne Software lebt von Integration - SAP, DATEV, CRM, Webshop. Welche API-Architekturen heute Standard sind und warum schlecht geplante Schnittstellen die häufigste Ursache für Projektverzögerungen sind.

März 2026 · 7 Min.Lesen →

Softwareentwicklung

Python im Unternehmen: Wann sich die Sprache wirklich lohnt

Python hat sich in Automatisierung, Datenverarbeitung und KI-Integration zur Lingua franca entwickelt. Für welche Aufgaben sich Python im Mittelstand tatsächlich eignet - und wo andere Sprachen weiterhin überlegen sind.

Januar 2026 · 6 Min.Lesen →

KI-Integration

RAG-Systeme im Unternehmen: Wie Sie Ihr eigenes Wissen für KI nutzbar machen

Large Language Models kennen das Internet - aber nicht Ihr Unternehmen. Mit Retrieval Augmented Generation (RAG) machen Sie interne Dokumente, Verträge und Produktdaten für KI-Systeme zugänglich, ohne sensible Daten preiszugeben.

Oktober 2025 · 7 Min.Lesen →

KI-Integration

KI-Agenten im Mittelstand: Wie KMU von Large Language Models profitieren

KI ist längst kein Thema mehr, das nur Großkonzernen vorbehalten ist. Welche konkreten Einsatzmöglichkeiten sich für KMU ergeben - und warum der Einstieg einfacher ist als gedacht.

April 2025 · 7 Min.Lesen →

Legacy-Modernisierung

Delphi-Anwendungen in 2025: Modernisieren oder neu entwickeln?

Viele Unternehmen betreiben noch heute geschäftskritische Software in Delphi. Wann lohnt sich eine Migration, wann ist eine Weiterentwicklung die bessere Wahl?

Mai 2025 · 8 Min.Lesen →

Projektmanagement

Festpreis oder Stundensatz? Was für Ihr Softwareprojekt wirklich Sinn ergibt

Die Wahl des richtigen Abrechnungsmodells entscheidet über Planungssicherheit und Projektrisiko. Ein ehrlicher Vergleich aus der Praxis - mit konkreten Empfehlungen.

Juni 2025 · 6 Min.Lesen →

Webentwicklung & SEO

Technisches SEO 2025: Warum Core Web Vitals über Ihren Google-Rang entscheiden

Google bewertet Webseiten heute nicht nur nach Inhalt, sondern nach messbaren Nutzererlebnissen. Was Core Web Vitals sind - und wie Sie davon profitieren.

Juli 2025 · 6 Min.Lesen →

IT-Sicherheit & Datenschutz

DSGVO-konforme Softwareentwicklung: Was Unternehmen wirklich wissen müssen

Datenschutz ist kein Hindernis, sondern Teil guter Softwareentwicklung. Welche konkreten Anforderungen die DSGVO stellt - und wie man sie von Anfang an richtig umsetzt.

August 2025 · 7 Min.Lesen →

KI-Integration

KI-Chatbot auf der eigenen Website: Lohnt sich das für kleine Unternehmen?

Ein KI-gestützter Chatbot beantwortet Kundenfragen rund um die Uhr - ohne Wartezeit. Was heute technisch möglich ist und worauf es bei der Umsetzung ankommt.

September 2025 · 5 Min.Lesen →

KI-Integration

KI-Agenten im Mittelstand: Wie kleine Unternehmen von Large Language Models profitieren

Künstliche Intelligenz hat in den letzten zwei Jahren einen Sprung gemacht, der noch vor Kurzem kaum vorstellbar war. Durch Modelle wie GPT-4 oder Claude ist es heute möglich, intelligente Software-Agenten zu entwickeln, die verstehen, was gemeint ist - nicht nur, was geschrieben steht. Für kleine und mittelständische Unternehmen öffnet das Türen, die bislang Konzernen mit eigenen KI-Abteilungen vorbehalten waren.

Dieser Artikel zeigt, wo der Einsatz von KI-Agenten für KMU heute schon wirtschaftlich Sinn ergibt - und wo nicht.

Was ist ein KI-Agent überhaupt?

Ein KI-Agent ist ein Softwaresystem, das auf Basis eines Large Language Models (LLM) eigenständig Aufgaben ausführt. Im Gegensatz zu einem einfachen Chatbot kann ein Agent mehrere Schritte selbstständig planen und durchführen: Er kann Daten abrufen, Texte analysieren, Formulare ausfüllen oder Entscheidungen treffen - und dabei auf externe Systeme wie Datenbanken oder APIs zugreifen.

Ein konkretes Beispiel: Ein KI-Agent, der eingehende Kundenanfragen per E-Mail liest, die Anfrage klassifiziert, die relevanten Kundendaten aus dem CRM-System abruft und dann eine passende Antwort formuliert - vollautomatisch, ohne menschliches Eingreifen für Standardfälle.

Drei Einsatzbereiche mit echtem Mehrwert für KMU

1. Automatisierte Dokumentenverarbeitung

Eingehende Angebote, Rechnungen, Verträge oder Bestellungen lesen, extrahieren und in bestehende Systeme einpflegen - das kostet in vielen KMU täglich wertvolle Stunden. Ein gut konfigurierter KI-Agent kann diese Aufgabe zu einem großen Teil übernehmen. Die Fehlerquote ist bei klar strukturierten Dokumenten überraschend gering, und das System lernt mit jeder Korrektur.

2. Intelligenter Kundendienst-Assistent

Ein KI-Chatbot auf der eigenen Website, der nicht nur auf vordefinierte Fragen antwortet, sondern echte Kundenanliegen versteht und bearbeitet, ist heute für einen Bruchteil der früheren Kosten realisierbar. Entscheidend ist dabei die Anbindung an produktspezifische Daten - nur dann liefert der Agent wirklich nützliche Antworten statt generischer Texte.

3. Analyse und Auswertung großer Datenmengen

Marktanalysen, Wettbewerbsbeobachtung oder die Auswertung von Kundenfeedback: Was früher externe Berater oder Stunden im Spreadsheet kostete, kann heute durch KI-gestützte Analyse in Minuten geschehen. Für KMU mit begrenzten Ressourcen ist das ein echter Wettbewerbsvorteil.

Was KI nicht ersetzt

KI-Agenten sind kein Allheilmittel. Sie eignen sich hervorragend für strukturierte, wiederholbare Aufgaben mit klaren Kriterien. Für komplexe strategische Entscheidungen, kreative Problemlösung oder empathische Kundengespräche bleibt der Mensch unverzichtbar. Der größte Fehler, den ich in der Praxis sehe: KI einzusetzen, ohne vorher den Prozess selbst zu verstehen und zu optimieren. KI automatisiert - aber sie verbessert keinen schlechten Prozess.

Der nächste Schritt für Ihr Unternehmen

Der Einstieg muss nicht mit einem großen Projekt beginnen. In den meisten Fällen lohnt es sich, mit einem klar abgegrenzten Anwendungsfall zu starten: einem Prozess, der heute viel manuelle Zeit kostet, klar definierte Eingaben und Ausgaben hat und nicht sicherheitskritisch ist. Innerhalb von wenigen Wochen ist ein erster funktionsfähiger Prototyp realistisch.

Wenn Sie wissen möchten, welche Prozesse in Ihrem Unternehmen sich für KI-Automatisierung eignen, sprechen Sie mich an. Das erste Gespräch ist kostenlos und unverbindlich.

Interesse an KI-Integration für Ihr Unternehmen?
Lassen Sie uns in einem kostenlosen Erstgespräch herausfinden, welche Prozesse sich für den Einsatz von KI-Agenten eignen.

Jetzt anfragen →

← Zurück zum Blog

Legacy-Modernisierung

Delphi-Anwendungen in 2025: Modernisieren oder neu entwickeln?

Delphi ist tot - das hört man seit Jahren. Und dennoch laufen in unzähligen deutschen Unternehmen täglich geschäftskritische Prozesse auf Software, die in Delphi oder Pascal geschrieben wurde. Lagerverwaltung, Kundendatenbanken, Abrechnungssysteme - oft seit Jahrzehnten zuverlässig im Einsatz, oft schlecht dokumentiert, und fast immer: nicht mehr wartbar durch die aktuelle IT-Generation.

Als jemand, der seit 2009 mit Delphi arbeitet und inzwischen über Jahre Erfahrung mit genau diesen Systemen hat, erlebe ich täglich, welche Entscheidungen Unternehmen vor dieser Frage treffen - und welche langfristig die richtige war.

Warum Delphi noch immer läuft

Delphi-Anwendungen sind in der Regel robust, schnell und gut auf spezifische Geschäftsprozesse zugeschnitten. Sie laufen seit Jahren stabil - genau das ist das Problem. Weil sie funktionieren, wird die Frage nach Modernisierung immer wieder aufgeschoben. Bis der Entwickler, der das System kennt, in Rente geht. Bis Windows eine inkompatible Version veröffentlicht. Bis eine kritische Sicherheitslücke auftaucht.

Der Handlungsbedarf entsteht selten geplant - er entsteht unter Druck.

Drei Szenarien - drei verschiedene Empfehlungen

Szenario 1: Die Software funktioniert, soll aber erweitert werden

Wenn das bestehende System stabil läuft und nur neue Funktionen benötigt, ist eine schrittweise Weiterentwicklung in Delphi oft die wirtschaftlichste Entscheidung. Voraussetzung: Es gibt einen Entwickler, der das System kennt und die Codebasis beherrscht. Eine vollständige Neuentwicklung wäre in diesem Fall überdimensioniert und riskant - denn jahrelang akkumuliertes Prozesswissen steckt in altem Code, der auf den ersten Blick unverständlich wirkt.

Szenario 2: Die Software soll in neue Systeme integriert werden

Wenn eine Delphi-Anwendung mit modernen Cloud-Diensten, REST-APIs oder anderen Systemen kommunizieren soll, ist eine Schnittstellenerweiterung der pragmatische erste Schritt. Delphi kann REST-APIs ansprechen und selbst bereitstellen - das ermöglicht die schrittweise Integration ohne vollständige Neuentwicklung. Ich habe diesen Ansatz mehrfach erfolgreich umgesetzt: Die Altanwendung bleibt das Herzstück, erhält aber moderne Anbindungen.

Szenario 3: Die Software ist nicht mehr wartbar oder skalierbar

Wenn die Codebasis so gewachsen ist, dass neue Entwickler sich nicht mehr zurechtfinden, wenn grundlegende Architekturentscheidungen einer Weiterentwicklung im Weg stehen, oder wenn die Plattformabhängigkeit ein Sicherheitsrisiko darstellt - dann ist eine Migration auf .NET / C# die richtige Entscheidung. Der Schlüssel liegt dabei in einer sorgfältigen Anforderungsanalyse: Was tut das System wirklich? Nicht was die Dokumentation sagt - sondern was der Code tatsächlich macht.

Was eine Migration kostet - und was sie bringt

Eine vollständige Migration ist kein Wochenendprojekt. Je nach Komplexität der Anwendung rechne ich mit mehreren Monaten bis zu einem Jahr Entwicklungszeit. Dafür erhält das Unternehmen eine Anwendung, die wartbar ist, von jedem C#-Entwickler verstanden werden kann, moderne Schnittstellen unterstützt und langfristig eine gesicherte Plattform hat.

Der häufigste Fehler: Eine Neuentwicklung beauftragen, ohne die Altanwendung wirklich zu verstehen. Das Ergebnis ist dann eine neue Oberfläche mit denselben logischen Fehlern darunter. Eine gründliche Analyse vor der Entwicklung ist keine Zusatzleistung - sie ist Voraussetzung für den Erfolg.

Meine Empfehlung

Wenn Sie eine Delphi-Anwendung betreiben und sich fragen, ob es Zeit für eine Modernisierung ist: Lassen Sie eine ehrliche Bestandsaufnahme durchführen, bevor Sie eine Entscheidung treffen. Ich tue das seit über Jahren - und sage Ihnen, was das System wirklich braucht, nicht was am teuersten klingt.

Haben Sie eine Delphi-Anwendung, die modernisiert werden soll?
Lassen Sie uns in einem kostenlosen Erstgespräch analysieren, welcher Weg für Ihr System der richtige ist.

Jetzt anfragen →

← Zurück zum Blog

Projektmanagement

Festpreis oder Stundensatz? Was für Ihr Softwareprojekt wirklich Sinn ergibt

Eine der häufigsten Fragen, die mir Kunden stellen, bevor ein Projekt beginnt: „Machen Sie das zum Festpreis oder nach Stunden?" Die ehrliche Antwort lautet: Es kommt darauf an. Und die Entscheidung, die Sie hier treffen, hat direkten Einfluss auf Planungssicherheit, Projektrisiko und letztendlich auf die Qualität des Ergebnisses.

Ich habe beide Modelle in der Praxis erlebt - als Auftragnehmer und als Engineering Manager, der Teams leitete. Hier ist, was ich dabei gelernt habe.

Das Festpreismodell: Sicherheit mit Bedingungen

Ein Festpreis funktioniert dann gut, wenn die Anforderungen zu Beginn klar und vollständig definiert sind. Der Auftraggeber weiß genau, was er will. Der Entwickler kann den Aufwand zuverlässig schätzen. Beide Seiten einigen sich auf Umfang und Preis - und halten sich daran.

In der Praxis ist das seltener der Fall als gedacht. Anforderungen ändern sich. Kunden entdecken während der Entwicklung neue Wünsche. Technische Gegebenheiten erweisen sich als komplexer als erwartet. Ein Festpreis, der auf unvollständigen Anforderungen basiert, führt zwangsläufig zu Konflikten - weil entweder der Entwickler auf Kosten sitzen bleibt oder der Kunde für jede Änderung Aufpreise zahlen soll.

Festpreis empfehle ich für: klar definierte Projekte mit stabilen Anforderungen, Neuentwicklungen auf Basis eines detaillierten Lastenhefts, abgeschlossene Teilprojekte wie eine einzelne Funktionserweiterung oder eine Webseite mit klarem Leistungsumfang.

Das Stundenmodell: Flexibilität mit Transparenz

Stundenbasierte Abrechnung klingt für viele Auftraggeber zunächst riskanter - weil das Endbudget offen ist. In der Praxis ist es oft das ehrlichere Modell. Der Entwickler hat keinen Anreiz, Aufwände kleinzurechnen, um den Auftrag zu gewinnen. Der Auftraggeber zahlt nur für tatsächlich geleistete Arbeit und behält die Flexibilität, Prioritäten während des Projekts anzupassen.

Voraussetzung ist gegenseitiges Vertrauen und transparente Kommunikation: regelmäßige Statusberichte, klare Stundenaufzeichnungen, offene Gespräche wenn der Aufwand höher wird als geplant.

Stundensatz empfehle ich für: Projekte mit sich entwickelnden Anforderungen, Wartung und laufende Weiterentwicklung bestehender Systeme, IT-Beratung und Konzeptionsarbeit, Projekte, bei denen die vollständige Anforderungsanalyse selbst Teil der Leistung ist.

Der hybride Ansatz

Was ich in der Praxis oft empfehle: eine Kombination. Die Konzeptionsphase und Anforderungsanalyse wird stundenbasiert abgerechnet - danach, wenn der Umfang klar ist, wird ein Festpreis für die Umsetzung vereinbart. So profitieren beide Seiten von der jeweils passenden Abrechnungsform.

Was Sie vor der Entscheidung fragen sollten

Sind meine Anforderungen vollständig und stabil? Wenn nicht, ist ein Festpreis riskant. Wie viel Flexibilität brauche ich während der Entwicklung? Vertraue ich dem Entwickler, transparent über Aufwände zu kommunizieren? Wie hoch ist mein Budget - und wie wichtig ist Planungssicherheit im Vergleich zu Flexibilität?

Es gibt kein universell richtiges Modell. Es gibt das für Ihr Projekt passende Modell - und das lässt sich am besten in einem ehrlichen Gespräch vor Projektbeginn klären.

Sie planen ein Softwareprojekt und sind unsicher, welches Modell passt?
Im kostenlosen Erstgespräch besprechen wir Ihr Projekt - und ich empfehle Ihnen das Modell, das für Sie am sinnvollsten ist.

Jetzt anfragen →

← Zurück zum Blog

Webentwicklung & SEO

Technisches SEO 2025: Warum Core Web Vitals über Ihren Google-Rang entscheiden

Viele Unternehmen investieren in Texte, Keywords und Backlinks - und wundern sich trotzdem, warum ihre Webseite in Google nicht die erhoffte Position erreicht. Ein entscheidender Faktor wird dabei häufig übersehen: technische Performance. Seit 2021 bewertet Google Webseiten nicht nur nach Inhalt, sondern nach messbaren Nutzererlebnissen - den sogenannten Core Web Vitals.

Was sind Core Web Vitals?

Core Web Vitals sind drei technische Kennzahlen, die Google zur Bewertung der Nutzererfahrung einer Webseite heranzieht:

Largest Contentful Paint (LCP)

LCP misst, wie schnell der größte sichtbare Inhalt einer Seite geladen wird - typischerweise ein Bild oder eine Überschrift. Google empfiehlt einen Wert von unter 2,5 Sekunden. Eine langsam ladende Seite verliert Besucher, bevor sie auch nur einen Satz gelesen haben.

Cumulative Layout Shift (CLS)

CLS misst, wie stark sich Seitenelemente während des Ladens verschieben. Jeder kennt das: Man klickt auf einen Button - und plötzlich lädt ein Bild nach und der Button hat sich verschoben. Ein hoher CLS-Wert frustriert Nutzer und wird von Google entsprechend bestraft.

Interaction to Next Paint (INP)

INP löste 2024 den First Input Delay ab und misst die Reaktionsfähigkeit einer Seite auf Nutzerinteraktionen. Klicks, Tippvorgänge, Formulareingaben - wie schnell reagiert die Seite darauf?

Warum das für lokale Unternehmen besonders wichtig ist

Bei lokalen Suchanfragen - „Softwareentwickler Freiburg", „IT-Dienstleister Freiburg" - konkurrieren in der Regel weniger Seiten um die vorderen Plätze als bei überregionalen Keywords. Das bedeutet: Technische Qualität kann hier den entscheidenden Unterschied machen. Eine gut optimierte Seite eines regionalen Anbieters kann eine inhaltlich reichhaltigere, aber technisch schwache Konkurrenzseite überholen.

Die häufigsten technischen SEO-Probleme in der Praxis

Nicht optimierte Bilder sind der häufigste Faktor für schlechte LCP-Werte. Bilder, die in Originalgröße eingebunden werden statt in optimierter Webgröße, verlangsamen den Seitenaufbau erheblich. Fehlende Größenangaben bei Bildern und Iframes führen zu Layout-Verschiebungen (CLS). Zu viele JavaScript-Ressourcen blockieren den Render-Prozess. Fehlende strukturierte Daten (Schema-Markup) lassen wertvolle Rich-Snippet-Chancen ungenutzt.

Was Sie konkret tun können

Der erste Schritt ist eine Messung des Ist-Zustands. Google PageSpeed Insights gibt kostenlos eine detaillierte Analyse Ihrer aktuellen Core Web Vitals - inklusive konkreter Verbesserungsvorschläge. Zielwert: ein Score von 90+ sowohl für Desktop als auch Mobil.

Dann folgen die Optimierungsmaßnahmen: Bilder in modernen Formaten (WebP, AVIF) und in passender Größe einbinden. Lazy Loading für Inhalte außerhalb des sichtbaren Bereichs. Kritisches CSS inline einbinden. JavaScript-Ressourcen verzögert laden. Schriftarten vorladen.

Das klingt technisch - ist es auch. Aber es ist Aufwand, der sich auszahlt: Bessere Performance bedeutet bessere Rankings, niedrigere Absprungraten und mehr Conversions.

Wollen Sie wissen, wie Ihre Webseite bei den Core Web Vitals abschneidet?
Ich analysiere Ihre Seite und zeige Ihnen, welche Maßnahmen den größten Effekt haben.

Jetzt anfragen →

← Zurück zum Blog

IT-Sicherheit & Datenschutz

DSGVO-konforme Softwareentwicklung: Was Unternehmen wirklich wissen müssen

Seit dem Inkrafttreten der DSGVO im Mai 2018 hat sich in der Softwareentwicklung grundlegend etwas verändert: Datenschutz ist keine nachträgliche Überlegung mehr, sondern muss von Anfang an Teil der Architektur sein. „Privacy by Design" und „Privacy by Default" - zwei Prinzipien, die in der Verordnung verankert sind - klingen abstrakt, haben aber sehr konkrete Auswirkungen auf die Art und Weise, wie Software entwickelt wird.

In meiner Praxis erlebe ich regelmäßig, dass Unternehmen entweder die DSGVO als bürokratisches Hindernis behandeln oder sich mit rechtlich fragwürdigen Lösungen behelfen. Beides ist vermeidbar.

Was Privacy by Design in der Praxis bedeutet

Der Grundsatz ist einfach: Datenschutz muss in die Systemarchitektur eingebaut werden, nicht im Nachhinein aufgesetzt. Konkret bedeutet das: Es werden nur die Daten erhoben, die tatsächlich für den jeweiligen Zweck benötigt werden (Datensparsamkeit). Personenbezogene Daten werden so früh wie möglich anonymisiert oder pseudonymisiert. Zugriffsrechte werden nach dem Least-Privilege-Prinzip vergeben - jeder Nutzer und jede Komponente erhält nur die Rechte, die für seine Funktion notwendig sind. Daten werden nur so lange gespeichert, wie es der Zweck erfordert.

Besonders kritisch: Medizinische und persönliche Daten

In meiner Arbeit für Facharztpraxen und Unternehmen im Sozialbereich habe ich gelernt, wie hoch die Anforderungen in bestimmten Branchen sind. Medizinische Daten gehören zur besonderen Kategorie nach Art. 9 DSGVO und erfordern ein erhöhtes Schutzniveau. Das betrifft nicht nur die Datenbank, sondern den gesamten Verarbeitungsprozess: Übertragung, Speicherung, Zugriffsverwaltung, Löschkonzepte.

Eine Arztpraxis, die Patientendaten in einer schlecht gesicherten Datenbank speichert oder ohne Verschlüsselung über das Netzwerk überträgt, riskiert nicht nur Bußgelder - sie riskiert das Vertrauen ihrer Patienten.

Technische Maßnahmen, die den Unterschied machen

Verschlüsselung aller gespeicherten personenbezogenen Daten (at rest). TLS-Verschlüsselung für alle Datenübertragungen (in transit). Vollständige Protokollierung von Datenzugriffen für Audit-Zwecke. Automatisierte Löschroutinen auf Basis definierter Aufbewahrungsfristen. Zwei-Faktor-Authentifizierung für Systeme mit Zugriff auf sensible Daten. Regelmäßige Datensicherungen mit definierten Wiederherstellungszeiten.

Was oft vergessen wird: der Auftragsverarbeitungsvertrag

Wer als Softwareentwickler im Auftrag eines Unternehmens auf personenbezogene Daten zugreift oder verarbeitet, ist nach DSGVO Auftragsverarbeiter. Das erfordert einen schriftlichen Auftragsverarbeitungsvertrag (AVV) zwischen Auftraggeber und Entwickler - ein Dokument, das in der Praxis leider noch immer häufig fehlt.

Ich weise meine Kunden proaktiv auf diese Anforderung hin und stelle entsprechende Vertragsunterlagen zur Verfügung. Das ist keine bürokratische Pflicht - es ist ein Zeichen professioneller Arbeitsweise.

Mein Fazit

DSGVO-konforme Softwareentwicklung ist kein Mehraufwand - sie ist gute Softwareentwicklung. Wer Datenschutz von Anfang an in seine Architektur einbaut, spart sich teure Nachbesserungen und schützt gleichzeitig seine Kunden und sein Unternehmen.

Sie entwickeln Software, die personenbezogene Daten verarbeitet?
Ich berate Sie zu datenschutzkonformer Architektur - von Anfang an.

Jetzt anfragen →

← Zurück zum Blog

KI-Integration

KI-Chatbot auf der eigenen Website: Lohnt sich das für kleine Unternehmen?

„Unser Chatbot beantwortet Ihre Frage gleich" - dieser Satz steht auf immer mehr Unternehmenswebseiten. Doch die Realität hinter diesen Versprechen ist oft ernüchternd: starre Entscheidungsbäume, die bei jeder unerwarteten Frage scheitern, frustrierte Nutzer und am Ende doch der Anruf in der Zentrale. Das muss nicht so sein. Moderne KI-gestützte Chatbots sind grundlegend anders - und für viele kleine Unternehmen heute erschwinglich.

Der Unterschied zwischen regelbasiert und KI-gestützt

Klassische Chatbots folgen fest programmierten Regeln: Wenn der Nutzer X schreibt, antwortet der Bot mit Y. Das funktioniert für sehr eng definierte Anwendungsfälle - aber schon eine leicht abweichende Formulierung führt zu „Ich habe Ihre Anfrage nicht verstanden".

KI-gestützte Chatbots auf Basis von Large Language Models verstehen den Inhalt einer Frage - unabhängig davon, wie sie formuliert wird. Sie können Kontext über mehrere Nachrichten hinweg behalten, aus einer Wissensbasis (Ihren eigenen Dokumenten, FAQs, Produktinformationen) antworten und bei Bedarf an einen menschlichen Mitarbeiter weiterleiten.

Konkrete Einsatzszenarien für kleine Unternehmen

Terminvereinbarung und Erstanfragen

Ein KI-Chatbot kann rund um die Uhr Erstanfragen entgegennehmen, grundlegende Informationen über Leistungen und Preise geben und Termine vorqualifizieren - ohne dass ein Mitarbeiter sofort verfügbar sein muss. Für Arztpraxen, Beratungsunternehmen oder Handwerksbetriebe kann das die Telefonlast erheblich reduzieren.

Produktberatung im E-Commerce

„Welches Produkt passt zu meinen Anforderungen?" - diese Frage stellen Kunden tausendfach täglich. Ein KI-Chatbot, der auf Basis Ihres Produktkatalogs berät, kann Kaufentscheidungen unterstützen und gleichzeitig wertvolle Daten über Kundenbedürfnisse liefern.

FAQ-Abdeckung und Kundenservice

Die häufigsten 20 Fragen machen in den meisten Unternehmen 80 % aller Supportanfragen aus. Ein gut trainierter KI-Chatbot kann diese Anfragen vollständig und korrekt beantworten - und schafft so Kapazitäten für komplexere Anliegen.

Was ein solches System heute kostet

Die Technologie ist heute weitaus zugänglicher als noch vor zwei Jahren. Die API-Kosten für Large Language Models sind deutlich gesunken. Eine einfache, aber effektive Implementierung - ein Chatbot, der auf Basis Ihrer Dokumentation antwortet und über Ihre Website erreichbar ist - ist für viele kleine Unternehmen heute in einem überschaubaren Budget realisierbar.

Entscheidend ist nicht die Technologie allein, sondern die sorgfältige Aufbereitung der Wissensbasis: Was soll der Chatbot wissen? Was soll er nicht beantworten? Wie soll er eskalieren, wenn er eine Frage nicht beantworten kann? Diese konzeptionelle Arbeit ist oft aufwendiger als die technische Implementierung - und über Erfolg oder Misserfolg entscheidend.

Mein Fazit

Ein KI-Chatbot ist kein Allheilmittel und kein Ersatz für menschliche Kommunikation. Aber für klar definierte Anwendungsfälle - Erstanfragen, FAQ-Abdeckung, Terminvorqualifizierung - ist er heute ein realistisches und wirtschaftliches Werkzeug, das rund um die Uhr arbeitet. Ohne Urlaubstage, ohne Wartezeiten.

Interesse an einem KI-Chatbot für Ihre Website?
Ich analysiere Ihren konkreten Anwendungsfall und zeige Ihnen, was heute technisch und wirtschaftlich möglich ist.

Jetzt anfragen →

← Zurück zum Blog

KI-Integration

RAG-Systeme im Unternehmen: Wie Sie Ihr eigenes Wissen für KI nutzbar machen

Large Language Models wie GPT-4 oder Claude kennen weite Teile des öffentlichen Internets - aber kein einziges Dokument aus Ihrem Unternehmen. Für viele praxisrelevante Aufgaben ist genau das aber entscheidend: Kundenhistorie im CRM, Produktdatenblätter, interne Richtlinien, Verträge, Handbücher. Die Antwort darauf heißt RAG - Retrieval Augmented Generation. Dieser Artikel erklärt, was dahinter steckt, warum es für die meisten Mittelständler der pragmatischere Weg als Fine-Tuning ist und wie ein erstes Projekt aussieht.

Was ist RAG überhaupt?

Die Grundidee ist einfach: Statt dem Sprachmodell alles „beizubringen", was es wissen soll, stellen Sie ihm zur Laufzeit genau die Informationen bereit, die es zur Beantwortung einer konkreten Frage braucht. Das Modell selbst bleibt das allgemeine, vortrainierte LLM - aber es antwortet auf Basis Ihrer Daten.

Technisch läuft das in drei Schritten ab: Zunächst werden Ihre Dokumente in kleine, semantisch sinnvolle Abschnitte zerlegt und als sogenannte Embeddings (Zahlenvektoren) in einer Vektordatenbank gespeichert. Stellt ein Nutzer eine Frage, wird auch diese Frage in einen Vektor übersetzt und die ähnlichsten Dokumenten-Ausschnitte werden gesucht. Diese Fundstellen werden dem LLM zusammen mit der Frage übergeben - und auf dieser Basis formuliert es eine präzise Antwort mit Quellenangabe.

RAG oder Fine-Tuning - was ist besser?

Eine Frage, die in nahezu jedem Erstgespräch aufkommt. Die ehrliche Antwort lautet für 90 % der mittelständischen Anwendungsfälle: RAG. Die Gründe dafür sind wirtschaftlicher und technischer Natur.

Fine-Tuning bedeutet, ein Modell mit eigenen Daten nachtrainieren zu lassen. Das ist teuer, setzt eine große Menge gut aufbereiteter Trainingsdaten voraus und muss bei jeder inhaltlichen Änderung wiederholt werden. RAG hingegen lässt sich inkrementell aktualisieren: Ein neues Dokument wird einfach indexiert und steht sofort zur Verfügung. Außerdem sind die Antworten nachvollziehbar - das Modell kann die Quelle zitieren, aus der es seine Information bezogen hat.

Konkrete Anwendungsfälle aus der Praxis

Interne Wissensdatenbank

Mitarbeiter stellen natürlichsprachige Fragen zu Unternehmensrichtlinien, Prozessen oder Produkten und erhalten präzise Antworten - inklusive Link zum Originaldokument. Besonders wertvoll für neue Kollegen, die sonst mehrere Wochen Einarbeitung brauchen.

Angebots- und Vertragsassistent

Ein RAG-System, das auf historische Angebote, Kundenspezifika und Produktkataloge zugreift, kann Vertriebsmitarbeiter beim Erstellen neuer Angebote deutlich entlasten. Besonders in Branchen mit vielen Varianten und Sonderausstattungen ist das ein echter Hebel.

Technischer Support

Support-Mitarbeiter finden in Sekunden die passende Lösung aus tausenden Tickets, Handbüchern und Service-Dokumentationen. Die Bearbeitungszeit pro Anfrage sinkt spürbar, die Qualität der Antworten steigt.

Datenschutz und Vertraulichkeit

Ein häufiger Einwand: „Ich möchte meine Unternehmensdaten nicht einfach in die Cloud schicken." Völlig berechtigt - und glücklicherweise technisch gut lösbar. Moderne RAG-Architekturen lassen sich so aufbauen, dass sensible Daten on-premises oder in einer geschützten Cloud-Umgebung verbleiben. Nur die konkrete Anfrage und der relevante Kontextausschnitt wird an das LLM übergeben - und auch das kann über datenschutzkonforme Anbieter mit Rechenzentren in der EU erfolgen.

Typische Stolpersteine

Der größte Fehler bei RAG-Projekten ist ungenügende Datenqualität. Wenn Ihre Dokumentation inkonsistent, veraltet oder widersprüchlich ist, wird das RAG-System genau diese Widersprüche zutage fördern. Der zweite häufige Fehler: zu optimistische Erwartungen an die Out-of-the-Box-Qualität. Ein RAG-System muss iterativ verbessert werden - durch besseres Chunking, bessere Embeddings, Prompt-Optimierung und regelmäßiges Feedback.

Ein realistischer Projektrahmen

Ein erstes, produktiv nutzbares RAG-System für einen klar abgegrenzten Anwendungsfall lässt sich typischerweise in vier bis acht Wochen umsetzen. Voraussetzung ist, dass die Ausgangsdokumente in digitaler Form vorliegen und strukturell halbwegs sauber sind. Den größten Teil des Aufwands macht nicht die KI, sondern die Datenaufbereitung aus - ein Punkt, den man in der Planung nicht unterschätzen sollte.

Möchten Sie Ihr Unternehmenswissen für KI zugänglich machen?
Ich analysiere mit Ihnen, welcher Datenbestand sich für ein RAG-System eignet und wie ein erster Piloteinsatz aussehen könnte.

Jetzt anfragen →

← Zurück zum Blog

Softwareentwicklung

Python im Unternehmen: Wann sich die Sprache wirklich lohnt

Python ist in den vergangenen Jahren zur Lingua franca für Automatisierung, Datenverarbeitung und KI-Integration geworden. Kaum eine andere Programmiersprache wird so breit eingesetzt - vom einmaligen Skript bis zur produktiven Anwendung. Doch nicht jedes Problem ist ein Python-Problem. Dieser Artikel beschreibt, wo die Sprache im Mittelstand echten Mehrwert liefert - und wo andere Werkzeuge besser geeignet sind.

Warum Python so erfolgreich ist

Python ist bewusst einfach gehalten: wenig Syntax-Ballast, lesbarer Code, eine enorme Standardbibliothek. Dazu kommt ein Ökosystem, das seinesgleichen sucht - von pandas für Datenanalyse über requests für API-Kommunikation bis zu den führenden KI-Bibliotheken wie PyTorch, LangChain oder OpenAI SDK. Dadurch lassen sich auch komplexe Aufgaben mit überschaubarem Aufwand umsetzen.

Wo sich Python im Mittelstand wirklich lohnt

1. Automatisierung wiederkehrender Aufgaben

Excel-Listen konsolidieren, Daten aus verschiedenen Systemen zusammenführen, Reports generieren, E-Mails versenden: Klassische Tätigkeiten, die in vielen Unternehmen täglich anfallen. Ein Python-Skript, das diese Aufgaben erledigt, ist oft innerhalb von Tagen geschrieben und spart auf Dauer enorm viel Zeit. Die Sprache ist geradezu dafür gemacht.

2. Datenverarbeitung und Analyse

Für das Einlesen, Bereinigen, Transformieren und Analysieren von Daten - insbesondere aus CSV, Excel, Datenbanken oder APIs - ist Python mit pandas und numpy heute das produktivste Werkzeug am Markt. Was in Excel an Grenzen stößt, ist in pandas eine Zeile Code.

3. KI-Integration und Machine Learning

Sämtliche relevanten KI-Frameworks werden primär in Python bereitgestellt. Wer LLMs, Embedding-Modelle, Vektordatenbanken oder klassisches Machine Learning einsetzen möchte, kommt an Python nicht vorbei. Auch als „Klebstoff" zwischen verschiedenen KI-Diensten und bestehenden Systemen ist die Sprache erste Wahl.

4. Webservices und APIs

Mit Frameworks wie FastAPI lassen sich robuste, moderne REST-APIs in wenigen hundert Zeilen Code realisieren - inklusive automatischer OpenAPI-Dokumentation und Typ-Validierung. Ideal, um bestehende Systeme über sauber definierte Schnittstellen miteinander zu verbinden.

Wo Python nicht die richtige Wahl ist

So universell Python einsetzbar ist - es gibt Bereiche, in denen andere Sprachen klar überlegen sind. Hochperformante Desktop-Anwendungen mit umfangreicher Geschäftslogik sind in C# oder Delphi deutlich besser aufgehoben. Für sicherheitskritische Echtzeitsysteme eignen sich kompilierte Sprachen mit strenger Typprüfung besser. Und bei mobilen Apps führt ohnehin kein Weg an den jeweiligen nativen Ökosystemen vorbei.

Integration mit bestehenden Systemen

Ein häufiges Missverständnis: Python sei eine Alternative zu bestehenden Unternehmenssystemen. In der Praxis ist das Gegenteil richtig. Python entfaltet seinen größten Nutzen oft in Kombination mit bestehenden Anwendungen - etwa als Automatisierungsschicht über einer Delphi-Anwendung, als Integration zwischen ERP und Webshop oder als intelligenter Filter zwischen Legacy-System und moderner Cloud-API.

Was bei der Einführung zu beachten ist

Ein ungeschriebenes Gesetz: Jedes Python-Skript, das länger als drei Monate nützlich ist, wird zur produktiven Anwendung. Das heißt: Schon beim ersten Skript sollte auf saubere Struktur, Versionsverwaltung (Git), Abhängigkeiten (requirements.txt oder uv) und eine minimale Testabdeckung geachtet werden. Andernfalls entsteht über die Jahre ein Wildwuchs, der später nur schwer beherrschbar ist.

Ebenso wichtig: Wer Python ernsthaft im Unternehmen einsetzt, sollte Verantwortlichkeiten klären. Wer pflegt die Skripte? Wer aktualisiert Abhängigkeiten? Wer stellt sicher, dass sicherheitskritische Updates eingespielt werden? Python ist einfach zu lernen - aber produktiver Python-Einsatz erfordert die gleiche Sorgfalt wie jede andere produktive Software.

Sie möchten Prozesse mit Python automatisieren oder modernisieren?
Ich berate Sie ehrlich, ob und wo Python der richtige Hebel ist - und setze die Lösung pragmatisch um.

Jetzt anfragen →

← Zurück zum Blog

Softwareentwicklung

Schnittstellen & APIs: Warum saubere Integration über den Erfolg von Software entscheidet

Moderne Unternehmenssoftware ist kein in sich abgeschlossenes System mehr. Sie lebt von Integration: ERP spricht mit Webshop, Buchhaltung mit DATEV, CRM mit Marketing-Automation, Produktion mit Logistik. Das Nervensystem dieser vernetzten Welt sind Schnittstellen - oder neudeutsch: APIs. Wer sie gut plant, gewinnt Flexibilität und Zeit. Wer sie nachlässig behandelt, produziert technische Schulden, die Jahre später schmerzhaft zurückkommen.

Was eine API wirklich ist

Eine API - Application Programming Interface - ist ein klar definierter Vertrag zwischen zwei Systemen: „Wenn du mir das schickst, bekommst du das zurück." Alles, was dahinter passiert, ist aus Sicht des Aufrufers unwichtig. Dieser Abstraktionsgewinn ist das Entscheidende: Systeme können unabhängig voneinander weiterentwickelt werden, solange sich niemand an den vereinbarten Vertrag hält.

In der Praxis begegnet man heute vor allem drei Arten von Schnittstellen: klassische REST-APIs für die meisten Business-Anwendungen, GraphQL für datenintensive Frontend-Szenarien und Webhooks für ereignisgetriebene Benachrichtigungen. Dazu kommen in der deutschen Unternehmenslandschaft noch immer SOAP-Services, klassische Datei-Schnittstellen (CSV, XML) und proprietäre Protokolle wie DATEV Rechnungswesen-Import.

Typische Integrationsszenarien im Mittelstand

Buchhaltungs- und Steuerberater-Integration

DATEV-Anbindungen sind in Deutschland der Klassiker - und in vielen Projekten die häufigste Ursache für Verzögerungen. Der Grund: Die Schnittstellen sind historisch gewachsen, die Dokumentation teils unvollständig, und Abstimmung mit dem Steuerberater ist erforderlich. Wer das früh plant, spart später viele Iterationen.

ERP- und Warenwirtschaftsanbindung

SAP, Microsoft Dynamics, Sage, proALPHA oder individuelle Warenwirtschaftssysteme: Kaum ein Softwareprojekt im Mittelstand kommt ohne Anbindung an das führende ERP-System aus. Die Herausforderung liegt meist weniger in der Technik als in den Datenmodellen: Welches System ist führend für Kundenstammdaten? Wie werden Artikeldaten synchronisiert? Wer definiert die Schnittstelle?

Webshop und Marketplaces

Shopware, WooCommerce, Shopify, Amazon, eBay - jede Plattform bringt ihre eigene API-Welt mit. Gerade hier zahlt sich ein sauberes Integrations-Design aus: Wer seine Shop-Anbindung als austauschbaren Adapter baut, kann später den Anbieter wechseln, ohne das gesamte Backend umzustellen.

Die fünf häufigsten Fehler bei API-Projekten

Aus der Praxis heraus - und durchaus selbstkritisch - hier die Fehler, die in der Schnittstellenentwicklung immer wieder auftreten:

  • Keine Versionierung. Eine API ohne Versionsstrategie ist eine tickende Zeitbombe. Sobald sich etwas ändert, brechen alle abhängigen Systeme zusammen.
  • Unklare Authentifizierung. Wer API-Keys im Quellcode hinterlegt, wer OAuth missversteht, wer Secrets unverschlüsselt speichert - hier passieren die meisten Sicherheitsvorfälle.
  • Keine Idempotenz. Was passiert, wenn ein Webhook zweimal ankommt? Wenn eine Bestellung versehentlich doppelt gesendet wird? Idempotente APIs beantworten das souverän.
  • Schwache Fehlerbehandlung. Eine gute API gibt nicht nur 200 oder 500 zurück, sondern kommuniziert klar, was schiefgelaufen ist - inklusive strukturierter Fehlercodes.
  • Tighte Kopplung. Wenn zwei Systeme sich gegenseitig so gut kennen, dass sie nur gemeinsam deployt werden können, ist die Architektur verunglückt.

Best Practices für saubere Schnittstellen

Eine gute API ist wie ein guter Vertrag: eindeutig, versioniert, dokumentiert und für beide Seiten nachvollziehbar. Konkret bedeutet das: Verwenden Sie offene Standards wie OpenAPI zur Spezifikation, damit Dokumentation und Code nicht auseinanderlaufen. Versionieren Sie über URL oder Header (/v1/, /v2/), niemals implizit. Protokollieren Sie alle API-Aufrufe mit Zeitstempel, Payload-Hash und Response-Code - das spart bei Support-Fällen Stunden. Und: Schreiben Sie Tests gegen Ihre API, nicht nur gegen Ihren internen Code. Schnittstellen sind öffentliche Versprechen.

Mein Fazit

Schlecht geplante Schnittstellen sind nach meiner Erfahrung die häufigste Einzelursache für gescheiterte Softwareprojekte im Mittelstand - noch vor unklaren Anforderungen und unterschätzten Komplexitäten. Die gute Nachricht: Es ist kein Hexenwerk, sie richtig zu bauen. Man muss nur bewusst entscheiden, dokumentieren und disziplinieren - und akzeptieren, dass eine API, die einmal live ist, ein Vertrag ist, den man nicht leichtfertig brechen kann.

Sie planen ein Projekt mit Schnittstellen zu SAP, DATEV, CRM oder Webshop?
Ich plane mit Ihnen die Integrationsarchitektur von Anfang an sauber - damit Sie später nicht wochenlang Fehler suchen.

Jetzt anfragen →

← Zurück zum Blog

Webentwicklung & SEO

SEO 2026: Was sich geandert hat und welche technischen Faktoren heute wirklich zahlen

Google hat in den vergangenen zwei Jahren mehr verandert als in den funf davor. Mit der Einfuhrung von KI-gestutzten Suchergebnissen (AI Overviews), dem Wechsel von FID zu INP als Core-Web-Vital und dem starkeren Gewicht von echten Nutzersignalen haben sich die Spielregeln fur Suchmaschinenoptimierung grundlegend verschoben.

Was ist INP und warum ist es wichtig?

Seit Marz 2024 ist Interaction to Next Paint (INP) offizieller Core-Web-Vital und hat den alteren FID-Wert ersetzt. Wahrend FID nur die erste Interaktion auf einer Seite mab, bewertet INP jede Nutzerinteraktion wahrend des gesamten Besuchs. Ein INP-Wert unter 200 Millisekunden gilt als gut, uber 500 ms als verbesserungsbedurftig. Fur viele Websites bedeutet das: schwerfalle JavaScript-Frameworks und blockierende Event-Handler werden jetzt direkt in Rankings sichtbar.

AI Overviews verandern das Klickverhalten

Googles AI Overviews zeigen fur viele Suchanfragen direkt eine KI-generierte Zusammenfassung ganz oben in den Ergebnissen. Bei Informationsanfragen, die fruher zu einem direkten Klick gefuhrt hatten, bleiben Nutzer heute ofter auf der Suchergebnisseite. Was funktioniert: strukturierte Inhalte, die als Quelle fur AI Overviews zitiert werden. Schema.org-Markup, klar gegliederte Artikel mit H2/H3-Struktur und faktisch dichte Texte erhohen die Chance, in der KI-Zusammenfassung als Link zu erscheinen.

Technische SEO-Faktoren, die heute zahlen

LCP (Largest Contentful Paint): Unter 2,5 Sekunden. Das groste sichtbare Element der Seite muss schnell geladen sein.
CLS (Cumulative Layout Shift): Unter 0,1. Elemente durfen sich nicht unerwartet verschieben.
INP (Interaction to Next Paint): Unter 200 ms. Jede Interaktion muss flussig reagieren.

Eine saubere crawlbare Struktur, korrekte canonical-Tags, vollstandige hreflang-Implementierung fur mehrsprachige Seiten und ein valides robots.txt gehoren weiterhin zur Pflicht. Wer diese Basics nicht beherrscht, verschenkt Potenzial, egal wie gut der Content ist.

Was KMU jetzt tun sollten

PageSpeed Insights regelmaig prufen und INP-Probleme beheben, Schema.org-Markup fur LocalBusiness und Blog-Artikel korrekt einbinden, HTTPS erzwingen (inklusive HSTS), og:image und og:title fur alle wichtigen Seiten pflegen. Der groste Hebel bleibt inhaltlich: Texte, die echte Fragen beantworten, klar strukturiert sind und faktisch belastbar sind, ranken besser als je zuvor. KI-generierter Content ohne echte Substanz wird von Google zunehmend erkannt und abgewertet.

Fazit

SEO 2026 belohnt das, was gute Softwareentwicklung schon immer ausgezeichnet hat: saubere Struktur, Geschwindigkeit, Verlasslichkeit und inhaltliche Tiefe. Die technischen Anforderungen sind gestiegen - aber wer sie erfullt, hat einen nachhaltigen Vorteil gegenuber Wettbewerbern, die SEO noch als Nachgedanken behandeln.

Sie mochten die technische SEO Ihrer Website verbessern?
Ich analysiere Ihre Seite, identifiziere die wichtigsten Hebel und setze die Masnahmen direkt um.

Jetzt anfragen →

← Zuruck zum Blog

IT-Sicherheit & Datenschutz

DSGVO und KI-Tools: Was Unternehmen bei der Integration von Sprachmodellen beachten mussen

ChatGPT, Microsoft Copilot, Google Gemini, Claude - KI-Assistenten sind produktiv, aber datenschutzrechtlich heikel. Wer als Unternehmen KI-Tools einsetzt, ohne die datenschutzrechtlichen Rahmenbedingungen zu klaren, riskiert Bußgelder, Vertragsstrafen und Datenverluste. Dieser Artikel zeigt die wichtigsten Risiken und wie man sie sauber lost.

Das Grundproblem: Daten verlassen das Unternehmen

Wenn ein Mitarbeiter einen Kundenbrief in ChatGPT einfugt, um ihn umzuformulieren, verlassen personenbezogene Daten das Unternehmen. Sie werden - je nach Anbieter und Einstellung - moglicherweise fur das Training zukunftiger Modelle verwendet. Das ist datenschutzrechtlich problematisch, selbst wenn es technisch simpel ist. Artikel 28 DSGVO schreibt vor, dass Unternehmen mit Auftragsverarbeitern einen Auftragsverarbeitungsvertrag (AVV) abschliesen mussen. Viele Unternehmen nutzen KI-Tools, ohne diesen Vertrag abgeschlossen zu haben.

Welche Daten sind besonders kritisch?

Nicht alle Daten sind gleich riskant. Offentlich verfugbare Produktbeschreibungen oder allgemeine Textentwurfe sind unkritisch. Heikel wird es bei: Kundennamen, E-Mail-Adressen oder Telefonnummern, Vertragsdetails oder Angebotsinformationen, Personaldaten von Mitarbeitern und Gesundheitsdaten oder anderen besonderen Kategorien nach Art. 9 DSGVO.

Losungsansatze fur den Unternehmenseinsatz

Unternehmensvertrage mit AVV

Die meisten groben Anbieter bieten Business- oder Enterprise-Tarife an, die einen AVV einschlieben und Training auf Basis Ihrer Daten deaktivieren. OpenAI ChatGPT Enterprise, Microsoft Copilot for Microsoft 365 und Google Workspace mit Gemini sind Beispiele.

EU-konforme Anbieter bevorzugen

Anbieter mit Rechenzentren in der EU - wie Azure OpenAI Service in Sweden North oder Mistral AI aus Frankreich - erleichtern die DSGVO-Compliance erheblich. Daten bleiben im europaischen Rechtsraum.

On-Premises oder Private Deployment

Fur besonders sensible Daten ist eine selbst gehostete Losung die sicherste Option. Open-Source-Modelle wie Llama, Mistral oder Qwen lassen sich auf eigenen Servern oder in einer privaten Cloud betreiben. Die Modellqualitat ist heute fur viele Anwendungsfalle vollkommen ausreichend.

Pseudonymisierung vor der Eingabe

Eine pragmatische Zwischenlosung: Personenbezogene Daten werden vor der Ubergabe an das KI-Tool durch Platzhalter ersetzt. Ein Kundenname wird zu "KUNDE_A", eine E-Mail-Adresse zu "[E-MAIL]". Das Ergebnis wird zuruckubersetzt - aufwandig, aber datenschutzrechtlich deutlich sauberer.

Organisatorische Masnahmen

Technik allein reicht nicht. Unternehmen, die KI-Tools einsetzen, sollten klare interne Richtlinien definieren: Welche Daten durfen in welche Tools eingegeben werden? Mussen Mitarbeiter geschult werden? Muss das KI-Tool im Verarbeitungsverzeichnis nach Art. 30 DSGVO dokumentiert werden? In vielen Fallen: ja.

Fazit

DSGVO-konformer KI-Einsatz ist kein Hindernis, sondern eine Planungsaufgabe. Wer von Anfang an den richtigen Anbieter wahlt, den AVV abschlieSt und klare interne Regeln definiert, kann KI produktiv und sicher einsetzen. Die Alternative - unkontrollierter Einsatz durch Mitarbeiter - ist das eigentliche Risiko.

Sie planen den Einsatz von KI-Tools und wollen es datenschutzrechtlich sauber losen?
Ich berate Sie bei der Auswahl des richtigen Ansatzes und implementiere eine DSGVO-konforme Losung.

Jetzt anfragen →

← Zuruck zum Blog

KI-Integration

Autonome KI-Agenten: Was sie konnen, was sie nicht konnen und wann sie sich lohnen

KI-Agenten sind der nachste Schritt nach dem Chatbot. Wahrend ein Chatbot antwortet, handelt ein Agent: Er plant Schritte, ruft Tools auf, iteriert uber Ergebnisse und arbeitet so lange, bis ein Ziel erreicht ist. Das klingt beeindruckend - und es ist es auch. Aber es ist kein Allheilmittel, und wer unrealistische Erwartungen mitbringt, wird enttauscht.

Was ein KI-Agent konkret tut

Ein KI-Agent kombiniert ein Sprachmodell mit einer Reihe von Werkzeugen: Websuche, Code-Ausfuhrung, Datenbankzugriff, E-Mail-Versand, API-Aufrufe. Das Sprachmodell entscheidet, welches Tool wann eingesetzt wird, wertet die Ergebnisse aus und plant den nachsten Schritt. Dieser Zyklus - Denken, Handeln, Beobachten, neu Denken - wird als ReAct-Pattern bezeichnet und ist die Grundlage der meisten modernen Agentenframeworks. Bekannte Frameworks: LangGraph, AutoGen, CrewAI, das Anthropic Agents SDK.

Konkrete Anwendungsfalle, die heute funktionieren

Recherche und Auswertung

Ein Agent, der selbststandig eine Liste von Wettbewerbern analysiert, Preise recherchiert, Texte zusammenfasst und einen strukturierten Bericht erstellt - das ist heute zuverlassig umsetzbar. Solche Aufgaben haben klare Ziele, tolerieren kleinere Fehler und sind nicht zeitkritisch.

Datenverarbeitung mit menschlicher Freigabe

Eingehende Dokumente klassifizieren, vorverarbeiten und zur menschlichen Freigabe vorlegen - das sogenannte Human-in-the-Loop-Muster - funktioniert sehr gut. Der Agent ubernimmt den repetitiven Teil, der Mensch die finale Entscheidung bei unklaren Fallen.

Code-Generierung und -Review

Agenten, die automatisch Unit-Tests generieren, Migrations-Skripte schreiben oder Code-Reviews durchfuhren, sind in der Softwareentwicklung heute produktiv einsetzbar. Voraussetzung: klare Spezifikationen und ein Review-Schritt durch einen Entwickler.

Wo Agenten heute noch scheitern

Uberall dort, wo Fehler teuer sind, Ziele unklar sind oder die Werkzeugpalette nicht vollstandig ist. Ein Agent, der selbststandig Bestellungen auslost, Vertrage unterzeichnet oder Produktionsprozesse steuert, ist heute noch nicht zuverlassig genug fur den unbeaufsichtigten Einsatz. Die Fehlerrate realer Agenten ist hoher, als Marketing-Demos vermuten lassen. Das liegt nicht am Modell - es liegt daran, dass autonome Entscheidungsketten jeden Fehler verstarken.

Wann lohnt sich der Einsatz?

Drei Kriterien machen Agenten-Einsatz sinnvoll: Das Ziel ist klar definierbar. Fehler sind reversibel oder werden vor dem Commit gepruft. Der manuelle Aufwand fur die gleiche Aufgabe ist hoch genug, dass sich Entwicklung und Betrieb rechnen. Wenn alle drei zutreffen, lohnt sich die Investition. Wenn eines fehlt, sollte man mit einer einfacheren Losung beginnen.

Wie ein erstes Agenten-Projekt aussieht

Sinnvoll ist ein klar abgegrenzter Pilotfall mit Human-in-the-Loop. Typischer Zeitrahmen: vier bis acht Wochen bis zum ersten produktiv nutzbaren Agenten. Den grosten Aufwand macht nicht das Agentenframework, sondern die Integration in bestehende Systeme und die Definition der richtigen Tools und ihrer Fehlerfalle.

Sie mochten einen KI-Agenten fur einen konkreten Anwendungsfall entwickeln?
Ich analysiere mit Ihnen, ob und wie ein Agent in Ihrem Kontext sinnvoll ist - und setze den Piloten um.

Jetzt anfragen →

← Zuruck zum Blog

KI-Integration

Claude Fable 5 wird abgekündigt: Was Entwickler bei KI-Modell-Migrationen beachten müssen

Anthropic hat die Abschaltung von Claude Fable 5 angekündigt. Für Unternehmen und Entwickler, die Anwendungen auf Basis dieses Modells betreiben, beginnt jetzt die Migrationsphase. Das ist kein Einzelfall - KI-Anbieter kündigen Modelle regelmäßig ab, oft mit überraschend kurzen Übergangsfristen. Wer heute KI in geschäftskritische Prozesse integriert, muss deshalb von Anfang an für Modellwechsel planen.

Warum KI-Modelle abgekündigt werden

Die Entwicklung von Sprachmodellen beschleunigt sich. Neue Modellgenerationen übertreffen ihre Vorgänger regelmäßig in Leistung, Effizienz und Sicherheit. Für Anbieter wie Anthropic ist es wirtschaftlich und technisch sinnvoll, ältere Modelle zu konsolidieren: Infrastrukturkosten sinken, Sicherheits-Patches müssen nur noch für aktuelle Versionen gepflegt werden, und Nutzer werden auf bessere Lösungen umgestellt. Das ist legitim - aber es bedeutet für Entwickler, dass jede KI-Integration ein Ablaufdatum hat.

Typische Probleme bei ungeplanten Migrationen

Wer eine KI-Integration ohne Abstraktionsschicht direkt gegen ein spezifisches Modell entwickelt hat, steht vor einem Aufwand, der weit über einen einfachen API-Parameterwechsel hinausgeht. Promptverhalten ändert sich zwischen Modellen erheblich: Ein Prompt, der mit Fable 5 zuverlässig strukturierte JSON-Ausgaben lieferte, kann mit einem Nachfolgemodell anders reagieren - mehr Text, andere Felder, geänderte Tonalität. Funktionen, die auf spezifischen Modellmerkmalen basierten, müssen neu getestet und häufig neu kalibriert werden.

Das Abstraktionsschicht-Prinzip

Die wichtigste Lektion lautet: Das konkrete Modell sollte nie tief in den Anwendungscode eingebettet sein. Eine Konfigurationsvariable oder ein zentrales Service-Objekt, das das Modell kapselt, erlaubt es, Modellwechsel ohne Codeänderungen in der Geschäftslogik durchzuführen. Änderungen beschränken sich dann auf Prompt-Anpassungen und Integrationstests - keine Architekturarbeit.

Prompt-Regression-Tests

Vor jeder Migration sollte eine Testbibliothek mit repräsentativen Eingaben und erwarteten Ausgaben existieren. Diese Tests laufen gegen das neue Modell und zeigen sofort, welche Prompts angepasst werden müssen. Ohne diese Grundlage ist eine Migration blind - man merkt Probleme erst in der Produktion.

Konkrete Schritte für die Fable-5-Migration

Wer heute noch auf Fable 5 setzt, sollte in dieser Reihenfolge vorgehen: Zunächst eine vollständige Bestandsaufnahme aller Anwendungen und Workflows, die das Modell nutzen. Dann der Aufbau einer Testbibliothek mit typischen Eingaben und akzeptablen Ausgaben. Danach Evaluation der Nachfolgemodelle - nicht anhand von Benchmark-Zahlen, sondern anhand der eigenen Anwendungsfälle. Schließlich eine schrittweise Migration mit Monitoring: erst Testbetrieb, dann paralleler Betrieb, dann vollständige Umstellung.

Was die Zukunft verlangt: Modell-agnostische Architektur

Die Abkündigung von Fable 5 ist eine gute Gelegenheit, bestehende KI-Integrationen auf eine robustere Basis zu stellen. Modell-agnostische Architekturen - bei denen das Modell ein austauschbarer Baustein ist, nicht das Fundament - sind heute der Stand der Technik. Frameworks wie LangChain, LlamaIndex oder das Anthropic Agents SDK unterstützen diese Trennung von Anfang an. Wer jetzt neu entwickelt, sollte diesen Weg konsequent gehen.

Die Abschaltung eines Modells ist keine Katastrophe, wenn man vorbereitet ist. Sie ist ein normaler Teil des KI-Lebenszyklus - genau wie Betriebssystem-Updates oder Bibliotheksversionen. Wer das von Anfang an einplant, spart sich teure Notfallmigrationen.

Sie betreiben eine KI-Integration auf Basis von Fable 5 oder einem anderen älteren Modell?
Ich helfe Ihnen bei der Migrationsplanung und dem Aufbau einer zukunftssicheren Architektur.

Jetzt anfragen →

← Zurück zum Blog

Softwareentwicklung

Vibe Coding in der Praxis: Was KI-gestützte Entwicklung für professionelle Software wirklich leistet

Vibe Coding ist das Schlagwort des Jahres: Mit einem natürlichsprachlichen Prompt zur fertigen Anwendung, ohne eine Zeile Code selbst schreiben zu müssen. Tools wie Cursor, GitHub Copilot und Claude Code haben das Konzept popularisiert. Zeit für eine nüchterne Einschätzung aus der Entwicklungspraxis.

Was Vibe Coding tatsächlich ist

Der Begriff, geprägt von Andrej Karpathy Anfang 2025, beschreibt einen Entwicklungsstil, bei dem man dem KI-System eine Absicht mitteilt und das Ergebnis akzeptiert, ohne den generierten Code im Detail zu verstehen. Das ist keine Metapher - es ist die ehrliche Beschreibung dessen, was viele Nutzer tun. Und es funktioniert: Für einfache Skripte, Prototypen, Konfigurationsdateien und Standard-CRUD-Anwendungen liefern heutige LLMs überraschend brauchbaren Code.

Wo Vibe Coding endet - und professionelle Entwicklung beginnt

Das Problem liegt nicht im generierten Code selbst. Es liegt darin, was nach dem ersten funktionierenden Ergebnis kommt. Professionelle Software muss gewartet werden - über Jahre. Sie muss skalieren, wenn sich Anforderungen ändern. Sie muss sicher sein, wenn Angreifer nach Lücken suchen. Sie muss mit anderen Systemen interagieren, auf die man keinen Einfluss hat. All das erfordert ein Verständnis des Codes, das beim reinen Vibe Coding systematisch verloren geht.

Das Testproblem

Code, den man nicht versteht, kann man nicht sinnvoll testen. Man kann KI-generierte Tests bekommen - aber ohne eigenes Verständnis der Geschäftslogik testet man, was der Code tut, nicht was er tun soll. Der Unterschied klingt akademisch, ist aber in der Praxis der häufigste Grund für Bugs, die erst beim Kunden auftreten.

Das Sicherheitsproblem

LLMs produzieren sicheren Code - meistens. Aber die Ausnahmen sind nicht zufällig verteilt. SQL-Injection, unsachgemäße Eingabevalidierung, schwache Authentifizierungslogik: Das sind genau die Bereiche, in denen ein Entwickler ohne tiefes Sicherheitsverständnis nicht merkt, dass etwas fehlt. Vibe Coding ohne Sicherheitsreviews ist ein kalkuliertes Risiko.

Der richtige Einsatz: KI als Werkzeug, nicht als Ersatz

In meiner täglichen Arbeit setze ich KI-Coding-Tools intensiv ein - aber als Werkzeug, nicht als Autopilot. Boilerplate generieren, Refactoring-Vorschläge einholen, Dokumentation schreiben, Unit-Tests aufsetzen: Das beschleunigt Entwicklung erheblich, ohne das Verständnis zu umgehen. Der Entwickler bleibt Autor - die KI wird zum produktiven Assistenten.

Für Unternehmen, die eigene Software entwickeln oder entwickeln lassen, gilt: Vibe-Coding-Prototypen sind ein hervorragendes Werkzeug für die Anforderungsvalidierung. Produktionscode, der Geschäftsprozesse trägt, braucht professionelle Entwicklung - mit oder ohne KI-Unterstützung.

Sie möchten KI-Coding-Tools sinnvoll in Ihre Entwicklungsprozesse integrieren?
Ich helfe Ihnen dabei, den richtigen Einsatzbereich zu finden und die Qualität sicherzustellen.

Jetzt anfragen →

← Zurück zum Blog

KI-Integration

MCP: Das Model Context Protocol und warum es KI-Integration grundlegend verändert

Bis vor kurzem war jede KI-Integration eine Einzellösung: Ein Sprachmodell bekommt Text, gibt Text zurück - alles andere muss der Entwickler drumherum bauen. Datenbankzugriff, API-Aufrufe, Dateisystemzugriff: Jede Anbindung war individuell implementiert und nicht übertragbar. Das Model Context Protocol (MCP) von Anthropic ändert das grundlegend.

Was MCP ist - und was es nicht ist

MCP ist ein offenes Protokoll, das standardisiert, wie KI-Modelle mit externen Werkzeugen und Datenquellen kommunizieren. Es definiert einen einheitlichen Kommunikationskanal zwischen einem KI-Client (z.B. Claude, Cursor, einem eigenen Agenten) und einem MCP-Server, der Werkzeuge bereitstellt. Wichtig: MCP ist kein Framework und kein Cloud-Service. Es ist eine Schnittstellendefinition - vergleichbar damit, was USB für Hardware ist.

Server und Clients

Ein MCP-Server stellt Werkzeuge bereit: Datei lesen, SQL-Abfrage ausführen, HTTP-Request senden. Ein MCP-Client ist das KI-System, das diese Werkzeuge aufruft. Einmal entwickelt, ist ein MCP-Server mit jedem kompatiblen Client nutzbar - ein Datenbankserver, der für Claude gebaut wurde, funktioniert ohne Änderungen auch mit anderen MCP-fähigen Systemen.

Was das für die Praxis bedeutet

Die wichtigste Konsequenz: KI-Integrationen werden wiederverwendbar. Wer heute einen MCP-Server für den Zugriff auf ein CRM-System baut, kann diesen Server für verschiedene KI-Anwendungen nutzen - einen Chatbot, einen internen Assistenten, einen automatisierten Workflow-Agenten. Die Integration muss nicht dreimal entwickelt werden.

Bestehende Systeme anbinden

Für Unternehmen mit gewachsener Software-Landschaft ist das besonders relevant. Ein MCP-Server kann als Adapter vor eine bestehende Datenbank, ein Legacy-System oder eine interne API geschaltet werden. Das KI-Modell sieht eine saubere Werkzeug-Schnittstelle - die Komplexität darunter bleibt verborgen. Ich habe diesen Ansatz bereits bei mehreren Integrationsprojekten eingesetzt: Der Aufwand für die MCP-Serverentwicklung amortisiert sich schnell, wenn das Werkzeug für mehr als einen Anwendungsfall genutzt wird.

Ökosystem und Reife

Das MCP-Ökosystem wächst schnell. Fertige Server für gängige Dienste - GitHub, Slack, Datenbankverbindungen, Websuche - sind bereits verfügbar und können direkt eingesetzt werden. Für unternehmensspezifische Systeme ist die Entwicklung eines eigenen Servers ein überschaubares Projekt: Das Protokoll ist gut dokumentiert, SDKs für Python und TypeScript sind verfügbar.

MCP löst kein KI-Problem - es löst ein Integrationsproblem. Und Integrationsprobleme sind in der Praxis oft das größere Hindernis als die KI-Technologie selbst. Das Protokoll verdient mehr Aufmerksamkeit, als es aktuell außerhalb der Entwickler-Community bekommt.

Sie möchten bestehende Systeme über MCP an KI-Modelle anbinden?
Ich entwickle für Sie den passenden MCP-Server und integriere ihn in Ihren KI-Workflow.

Jetzt anfragen →

← Zurück zum Blog

Recht & Compliance

EU AI Act: Transparenzpflichten für KI-Systeme und wie Sie sie umsetzen

Hinweis: Dieser Artikel wurde am 10. Juli 2026 überarbeitet. Die ursprüngliche Fassung bezog sich auf den Stichtag 2. August 2026. Mit dem Digital Omnibus hat die EU Ende Juni 2026 den Zeitplan des AI Act angepasst. Alle Details zu den verschobenen Fristen finden Sie in meinem Beitrag zum Digital Omnibus.

Die Transparenzpflichten des EU AI Act gehören zu den Anforderungen, die praktisch jedes Unternehmen mit KI-Einsatz im Kundenkontakt betreffen, nicht nur die Großkonzerne. Chatbots müssen sich als KI zu erkennen geben, KI-generierte Inhalte müssen gekennzeichnet werden. Der Digital Omnibus hat den Zeitplan entzerrt, die Kennzeichnungspflichten greifen nun gestaffelt ab Dezember 2026 statt bereits im August. An der Sache selbst ändert das nichts, nur an der verfügbaren Vorbereitungszeit. Wer die Umsetzung jetzt plant, arbeitet ohne Termindruck statt später unter Zwang.

Was die Transparenzpflichten verlangen

Die Anforderungen sind klarer, als viele befürchten, aber sie erfordern technische Umsetzungsarbeit, die nicht an einem Nachmittag erledigt ist. Betroffen sind im Wesentlichen drei Bereiche.

Zunächst die Chatbots und virtuellen Assistenten. Jedes KI-System, das im direkten Kundenkontakt natürlichsprachlich kommuniziert, muss sich als KI erkennbar machen, und zwar gleich zu Beginn der Interaktion und nicht erst auf Nachfrage. Das betrifft den Chatbot auf der Website genauso wie automatisierte E-Mail-Antworten und Sprachassistenten am Telefon.

Der zweite Bereich sind KI-generierte Inhalte. Texte, Bilder, Audio und Video, die mit KI erzeugt oder erheblich verändert wurden, müssen als solche gekennzeichnet sein, maschinenlesbar und bei synthetischen Medien mit realen Personen auch sichtbar. Für das Marketing bedeutet das, dass jedes KI-generierte Kampagnenbild und jeder synthetische Sprecher eine Kennzeichnung braucht.

Und schließlich die Systeme, die Emotionen oder biometrische Merkmale erkennen und verarbeiten. Sie müssen die betroffenen Personen aktiv darüber informieren. Das reicht von der Emotionserkennung in HR-Prozessen bis zur Gesichtserkennung an Zugangssystemen.

Wer eigene KI-Modelle anbietet

Wer eigene Sprachmodelle entwickelt oder anbietet, auch als internes Werkzeug für andere Entwickler, fällt unter die Regeln für KI-Modelle mit allgemeinem Verwendungszweck. Diese gelten bereits seit August 2025 und wurden vom Digital Omnibus nicht verschoben. Ab einem bestimmten Schwellenwert an Trainingsaufwand kommen zusätzliche Anforderungen an Dokumentation und Risikobewertung hinzu.

So gehen Sie die Umsetzung an

Am Anfang steht eine vollständige Liste aller KI-Systeme im Unternehmen, einschließlich der KI, die in Drittanbieter-Software eingebettet ist. Für jedes System sollte klar sein, was es tut, ob es direkt mit Kunden oder Mitarbeitern interagiert, ob es Inhalte erzeugt und ob es biometrische Daten verarbeitet.

Danach folgt die technische Umsetzung der Kennzeichnung. Bei Chatbots heißt das ein Hinweis zu Beginn jeder Konversation, deutlich erkennbar und nicht als versteckter Fußnotentext. Bei generierten Inhalten kommen eine sichtbare Kennzeichnung oder Metadaten im C2PA-Format in Frage. Beides lässt sich mit überschaubarem Aufwand in bestehende Systeme integrieren.

Bleibt die Dokumentation. Die umfangreichen Nachweispflichten für Hochrisiko-Systeme, etwa in der Kreditvergabe, bei Personalentscheidungen oder medizinischen Diagnosen, greifen nach dem Digital Omnibus erst ab Dezember 2027. Für die meisten Unternehmensanwendungen genügt es schon heute, festzuhalten, welches KI-System wo eingesetzt wird und wie die Kennzeichnung umgesetzt ist.

Was bei Nichtumsetzung droht

Die Aufsicht liegt in Deutschland bei einer noch zu benennenden nationalen Behörde. In der Anfangsphase ist mit Hinweisen und Abmahnungen zu rechnen, bevor Bußgelder verhängt werden. Die Erfahrung mit der DSGVO zeigt allerdings, dass aus Kulanz schnell Konsequenz wird. Der Bußgeldrahmen des AI Act reicht bis 15 Millionen Euro oder drei Prozent des weltweiten Jahresumsatzes.

Wer die Transparenzpflichten jetzt sauber implementiert, ist für die nächsten Stufen des AI Act deutlich besser aufgestellt. Ich sehe das weniger als Last denn als Investition in einen rechtssicheren KI-Einsatz. Dank der verschobenen Fristen ist die Umsetzung derzeit ohne Termindruck möglich, und genau das würde ich ausnutzen.

Sie setzen KI-Systeme im Kundenkontakt ein und sind unsicher, ob Ihre Lösung die Anforderungen des EU AI Act erfüllt?
Ich analysiere Ihren KI-Einsatz und helfe Ihnen bei der technischen Umsetzung der Compliance-Anforderungen.

Jetzt anfragen →

← Zurück zum Blog

IT-Sicherheit & Compliance

NIS2-Richtlinie 2026: Security by Design wird Pflicht für Software-Lieferanten

Die NIS2-Richtlinie ist seit dem 6. Dezember 2025 deutsches Recht, und zwar ohne Übergangsfrist. Was viele Unternehmen noch als künftiges Compliance-Thema behandeln, ist also längst Gegenwart. Die Diskussion konzentriert sich dabei meist auf die direkt betroffenen Unternehmen. Dabei wird gern übersehen, dass Software-Lieferanten und IT-Dienstleister über die Lieferkettenpflichten genauso in der Pflicht stehen, nur eben indirekt.

Wen NIS2 direkt trifft

NIS2 gilt für Unternehmen ab 50 Mitarbeitern oder 10 Millionen Euro Jahresumsatz in kritischen und wichtigen Sektoren. In Deutschland sind das rund 29.500 Unternehmen aus Bereichen wie Energie, Transport, Gesundheit, Finanzwesen, digitale Infrastruktur und öffentliche Verwaltung. Wer dazugehört, muss sich registrieren, Sicherheitsmaßnahmen nachweisen und Vorfälle innerhalb von 24 Stunden melden.

Für Entwickler und IT-Dienstleister ist ein anderer Punkt entscheidend. Die Richtlinie verpflichtet betroffene Unternehmen nämlich, ihre gesamte Lieferkette zu überprüfen, und schreibt vor, dass Sicherheitsmaßnahmen auch für Lieferanten und Dienstleister gelten. In der Praxis heißt das, dass jeder, der Software an ein NIS2-pflichtiges Unternehmen liefert, früher oder später von dessen Compliance-Team unter die Lupe genommen wird und nachweisen muss, dass die eigene Software sicher entwickelt wurde.

Was Security by Design konkret bedeutet

Das Konzept selbst ist nicht neu, aber NIS2 macht daraus eine nachweisbare Anforderung. Es reicht nicht mehr, am Ende eines Projekts einen Penetrationstest zu machen und die gefundenen Lücken zu schließen. Sicherheit muss von Anfang an in den Entwicklungsprozess integriert sein.

Das beginnt vor dem ersten Commit mit einem Threat Model. Welche Angriffsvektoren gibt es, welche Daten sind schützenswert, welche Schnittstellen lassen sich missbrauchen? Ein solches Modell muss nicht komplex sein, aber es muss existieren und die Design-Entscheidungen tatsächlich beeinflussen. OWASP bietet dafür kostenlose Methodiken an, die auch für kleinere Projekte gut funktionieren.

In der Entwicklung selbst geht es dann um Dinge, die ohnehin zu professioneller Arbeit gehören. Eingaben werden an allen Systemgrenzen validiert, Zugangsdaten stehen nicht im Code, sensible Daten werden verschlüsselt übertragen, Abhängigkeiten werden regelmäßig auf bekannte Schwachstellen geprüft und Sicherheitsaspekte sind Teil der Code-Reviews. Neu ist vor allem die Pflicht, das alles zu dokumentieren. Wer bisher sauber gearbeitet, aber nichts festgehalten hat, muss damit anfangen.

Dazu kommt die Frage der Update-Fähigkeit. Der Cyber Resilience Act, ein Schwestergesetz zu NIS2, verlangt von Produkten mit digitalen Elementen Sicherheitsupdates über den gesamten Lebenszyklus. Für Software bedeutet das klare Update-Prozesse, kommunizierte Support-Zeiträume und die Fähigkeit, kritische Lücken schnell zu schließen und die Korrektur auch auszurollen.

Die persönliche Haftung der Geschäftsführung

Eine Klausel der Richtlinie wird nach meiner Erfahrung besonders unterschätzt. Geschäftsführer haften persönlich für die Einhaltung der Sicherheitsanforderungen. Das heißt nicht, dass jede Geschäftsleitung zum IT-Sicherheitsexperten werden muss. Es heißt aber, dass Nichtwissen keine Entschuldigung mehr ist. Eine dokumentierte Sicherheitsstrategie, regelmäßige Schulungen für Mitarbeiter und ein Plan für den Ernstfall sind damit keine Kür mehr, sondern Mindestanforderung.

Was jetzt zu tun ist

Für Software-Entwickler und IT-Dienstleister ergibt sich eine klare Reihenfolge. Zuerst klären, ob man selbst unter NIS2 fällt. Dann prüfen, welche Kunden direkt betroffen sind und welche Anforderungen sie an ihre Lieferanten stellen werden. Und schließlich den eigenen Entwicklungsprozess an Security-by-Design-Prinzipien ausrichten und das Ganze dokumentieren.

NIS2 ist kein Papiertiger. Die Behörden haben Durchgriffsrechte, und erste Bußgelder gegen nicht konforme Unternehmen werden erwartet. Wer jetzt handelt, verschafft sich zudem einen handfesten Wettbewerbsvorteil, denn die Überprüfung der Lieferketten durch die betroffenen Unternehmen läuft bereits.

Sie möchten Ihren Entwicklungsprozess auf NIS2-Konformität prüfen oder Security by Design implementieren?
Ich analysiere Ihre aktuelle Sicherheitsarchitektur und helfe Ihnen bei der praxisnahen Umsetzung.

Jetzt anfragen →

← Zurück zum Blog

Softwareentwicklung

Green IT 2026: Nachhaltige Softwareentwicklung spart Kosten und erfüllt neue EU-Standards

Seit dem 1. Juli 2026 gelten für Rechenzentren in der EU neue gesetzliche Anforderungen. Verlangt werden PUE-Werte unter 1,2 und eine Wärmerückgewinnung von mindestens 10 Prozent. Bereits im Februar ist außerdem die ISO 20125 in Kraft getreten, die Nachhaltigkeitsanforderungen für digitale Dienste international standardisiert. Das klingt zunächst nach einem reinen Infrastruktur-Thema. Tatsächlich hat es direkte Konsequenzen für jeden, der Software entwickelt oder betreibt.

Warum Entwickler mitverantwortlich sind

Ineffizienter Code ist kein ästhetisches Problem. Er kostet Energie, und Energie kostet Geld. Die Verbindung zwischen Codequalität und Stromverbrauch ist dabei kürzer, als viele denken. Unnötige Datenbankabfragen, unkontrollierte Polling-Schleifen und überdimensionierte Instanzen treiben die Cloud-Rechnung genauso in die Höhe wie den CO₂-Fußabdruck. Nur etwa 30 Prozent der deutschen Unternehmen haben heute eine umfassende IT-Nachhaltigkeitsstrategie. Diese Lücke wird zum Risiko, sie ist aber auch ein echtes Einsparpotenzial.

Die ISO 20125 gibt Entwicklern erstmals einen internationalen Referenzrahmen an die Hand. Gefordert werden unter anderem die Messung und Dokumentation des Energieverbrauchs von Softwarekomponenten, die Optimierung von Datenübertragungen, ein effizienter Umgang mit Hardware-Ressourcen und die Berücksichtigung von Energieeffizienz schon im Designprozess. Für viele Unternehmen ist die Norm zunächst freiwillig. Öffentliche Auftraggeber und größere Unternehmenskunden werden entsprechende Nachweise aber zunehmend einfordern.

Wo die größten Hebel liegen

Nachhaltige Softwareentwicklung ist keine Weltanschauung, sondern Ingenieurarbeit. Und die größten Einsparpotenziale liegen genau dort, wo Entwickler ohnehin hinschauen sollten.

Der Klassiker sind Datenbankabfragen. Wo statt eines sauberen Joins hunderte Einzelabfragen laufen, kostet das nicht nur Laufzeit, sondern Energie. ORM-Frameworks verführen zu solchen Mustern, regelmäßiges Profiling und durchdachte Lazy-Loading-Konfigurationen schaffen Abhilfe. Eine gut optimierte Datenbankschicht kann den Ressourcenverbrauch einer Webanwendung nach meiner Erfahrung um 20 bis 40 Prozent senken.

Der zweite große Hebel ist die Dimensionierung der Infrastruktur. Überdimensionierte Container sind in vielen Cloud-Umgebungen der Normalfall, weil man auf Nummer sicher gehen will. In der Praxis laufen viele davon auf 10 bis 15 Prozent ihrer reservierten Kapazität. Konsequentes Ressourcen-Monitoring und Werkzeuge wie der Vertical Pod Autoscaler in Kubernetes senken die Cloud-Kosten unmittelbar, und was fürs Budget gilt, gilt genauso für den Energieverbrauch.

Und schließlich das Caching. Synchrone API-Aufrufe, die auf Ergebnisse warten, und fehlende Caching-Strategien gehören zu den häufigsten Energiefressern. Ereignisgesteuerte Architekturen und mehrstufiges Caching über Speicher, verteilten Cache und CDN reduzieren Last und Latenz gleichzeitig. Gut umgesetzt kann das die Serverlast um 60 bis 70 Prozent senken.

Der wachsende Druck über die Lieferkette

Nachhaltigkeitsberichte werden für immer mehr Unternehmen Pflicht, zunächst für die großen über die CSRD, danach schrittweise auch für kleinere über deren Lieferketten. Wer Software für Unternehmenskunden entwickelt, wird deshalb immer öfter nach dem Energieverbrauch seiner Produkte gefragt. Wer darauf eine belastbare Antwort hat, ist im Vorteil.

Green IT ist damit keine Zusatzaufgabe für idealistische Entwickler. Es ist Kosteneffizienz, Compliance und Wettbewerbspositionierung in einem. Die Werkzeuge zur Energiemessung wie Cloud Carbon Footprint oder der Measurement Guide der Green Software Foundation sind kostenlos, und die Ersparnisse sind real.

Sie möchten den Energieverbrauch Ihrer Softwaresysteme senken und gleichzeitig Cloud-Kosten optimieren?
Ich analysiere Ihre Architektur und identifiziere die größten Effizienzpotenziale.

Jetzt anfragen →

← Zurück zum Blog

KI-Integration

Agentic AI für den Mittelstand: Wie autonome KI-Agenten Geschäftsprozesse wirklich verändern

2024 war das Jahr der Chatbots, 2025 das Jahr der Copiloten, und 2026 ist das Jahr der Agenten. Der Unterschied ist fundamental. Ein Chatbot beantwortet Fragen, ein Copilot macht Vorschläge, ein Agent handelt. Er führt mehrstufige Aufgaben selbstständig aus, greift auf externe Systeme zu, trifft Entscheidungen und liefert Ergebnisse statt Antworten. In Deutschland nutzen inzwischen 41 Prozent der Unternehmen KI, fast dreimal so viele wie 2024. Der Großteil dieser Anwendungen beschränkt sich allerdings noch auf Textgenerierung. Der nächste Schritt, bei dem Agenten ganze Prozesse übernehmen, wird gerade vollzogen.

Was Agenten heute konkret leisten

Autonome Agenten sind keine Science-Fiction mehr. Die Technologie ist verfügbar, und die ersten Mittelständler liefern messbare Ergebnisse. Ein gutes Beispiel ist die Rechnungsverarbeitung. Ein Agent empfängt eingehende Rechnungen per E-Mail oder Upload, extrahiert Positionen und Beträge, gleicht sie mit den offenen Bestellungen im ERP ab, markiert Abweichungen zur manuellen Prüfung und bucht den Rest automatisch. Was früher zwei bis drei Minuten pro Rechnung gekostet hat, dauert Sekunden. Bei 500 und mehr Rechnungen im Monat kommen so mehrere Vollzeittage pro Jahr zusammen, die für wertschöpfende Arbeit frei werden.

Ähnlich sieht es bei der Angebotserstellung aus. Ein Agent zieht die Anforderungen aus der Kundenanfrage, durchsucht Produktkatalog und Preislisten, erstellt ein strukturiertes Angebot und legt es zur Freigabe vor. Aus Stunden werden Minuten. Komplexe Angebote mit vielen Abhängigkeiten bleiben Sache des Vertriebs, Standardangebote nicht mehr.

Auch im Betrieb von IT-Systemen tut sich einiges. Agenten überwachen Produktionsumgebungen, erkennen Anomalien, führen definierte Gegenmaßnahmen selbstständig durch, etwa den Neustart eines Dienstes oder die Skalierung einer Instanz, und protokollieren jeden Schritt. Der Unterschied zur klassischen Automatisierung liegt darin, dass Agenten auch auf Situationen reagieren können, die vorher niemand explizit vorgesehen hat.

Wie ein Produktionsagent aufgebaut ist

Ein produktiv einsetzbarer Agent ist kein einzelnes Modell, sondern ein System. Dazu gehören ein Orchestrator, also das Sprachmodell selbst, Werkzeuge wie APIs, Datenbanken und Dateisysteme, ein Gedächtnis aus Kurzzeitkontext und persistentem Speicher, dazu Grenzen, die der Agent nicht überschreiten darf, und definierte Punkte, an denen er pausiert und auf menschliche Bestätigung wartet.

Die größte Herausforderung ist dabei nicht die Fähigkeit des Modells, sondern die Frage, was der Agent nicht tun soll. Ein Agent, der Rechnungen bucht, darf keine Zahlungen auslösen. Einer, der E-Mails schreibt, darf sie nicht ohne Freigabe verschicken. Diese Grenzen zu definieren und technisch durchzusetzen ist die eigentliche Architekturaufgabe, und ohne menschliche Kontrollpunkte würde ich kein System in Produktion geben.

Für die Anbindung an die bestehende Systemlandschaft hat sich das Model Context Protocol als Standard etabliert. Ein einmal entwickelter MCP-Server für das CRM kann von verschiedenen Agenten genutzt werden, ohne dass die Integration jedes Mal neu gebaut werden muss.

Wo Agenten noch nicht funktionieren

Zum Projekterfolg gehört ehrliches Erwartungsmanagement. Agenten sind heute stark in strukturierten, regelbasierten Aufgaben mit klar definierten Eingaben und Ausgaben. Schwächer sind sie bei hochgradig kreativen Aufgaben, bei strategischen Entscheidungen mit vielen Variablen und in Situationen mit unvollständigen oder widersprüchlichen Informationen.

Der Einstieg gelingt deshalb am besten mit einem abgegrenzten, gut dokumentierten Prozess und nicht mit dem komplexesten Problem des Unternehmens. Ein erfolgreicher Pilotbetrieb baut internes Vertrauen auf und liefert das Fundament für die größeren Projekte danach.

Sie möchten einen Geschäftsprozess mit Agentic AI automatisieren und wissen nicht, wo Sie anfangen sollen?
Ich analysiere Ihre Prozesse, identifiziere geeignete Einstiegspunkte und entwickle einen passenden Agenten für Ihren Anwendungsfall.

Jetzt anfragen →

← Zurück zum Blog

Softwareentwicklung

API-First Architektur 2026: Warum skalierbare Software ohne saubere Schnittstellen scheitert

Im Mai 2026 haben Bremen und Nordrhein-Westfalen eine Deklaration für eine föderale API-Plattform unterzeichnet, nach dem Prinzip einmal entwickeln, überall nutzen. Das ist mehr als ein technisches Detail. Es zeigt, dass API-First inzwischen sogar in der deutschen Verwaltung angekommen ist. Die Privatwirtschaft ist da längst weiter. Wer heute neue Software ohne saubere API-Strategie in Betrieb nimmt, baut auf einem Fundament, das er in zwei Jahren wieder abreißen muss.

Was API-First wirklich bedeutet

API-First heißt nicht, dass man zuerst eine API entwickelt und danach eine Benutzeroberfläche. Es heißt, dass die API das primäre Design-Artefakt ist und alles andere, einschließlich der eigenen Oberfläche, als Konsument dieser API behandelt wird. Das klingt nach einer technischen Entscheidung, ist aber eine strategische.

Der Prozess beginnt mit der OpenAPI-Spezifikation und nicht mit dem Code. Die Spezifikation wird mit allen Beteiligten besprochen, überarbeitet und erst dann implementiert. Das hat sehr praktische Konsequenzen. Frontend-Teams können mit Mock-Servern parallel arbeiten, bevor das Backend fertig ist, Kunden können die Dokumentation vor der Implementierung prüfen, und Änderungen kosten im Design-Stadium einen Nachmittag statt Wochen in der Implementierung.

Dazu gehört auch, aus der Perspektive der Nutzer der Schnittstelle zu denken. Eine gute API ist nicht die, die sich am leichtesten implementieren lässt, sondern die, die sich am leichtesten verwenden lässt. Welche Daten braucht der Konsument, in welchem Format, mit welchen Fehlermeldungen, mit welcher Authentifizierung? Wer diese Fragen vor dem ersten Commit stellt, erspart allen Beteiligten viel Reibung.

Der neue Treiber heißt KI

Seit diesem Jahr gibt es einen weiteren Grund für API-First, und der wiegt schwer. Sprachmodelle, die Geschäftsprozesse automatisieren sollen, brauchen saubere, dokumentierte Schnittstellen. Eine undokumentierte, inkonsistente API kann ein KI-Agent nicht zuverlässig nutzen. Wer heute API-First baut, bereitet seine Systeme also ganz nebenbei auf die KI-Integration vor.

Das Model Context Protocol setzt genau hier an. Es standardisiert als Schicht über den APIs, wie KI-Systeme auf Werkzeuge zugreifen. Ein gut gestaltetes API-First-System lässt sich in MCP-Werkzeuge übersetzen, ohne die API selbst zu ändern. Die Investition in gutes API-Design zahlt sich damit doppelt aus, für die heutigen Integratoren und für die KI-Agenten von morgen.

Versionierung entscheidet über den Betrieb

Die häufigste Ursache für Integrationsprobleme in gewachsenen Systemlandschaften sind Breaking Changes ohne ordentliche Versionierung. In API-First-Projekten ist Versionierung von Anfang an Teil des Designs, mit Semantic Versioning, klaren Abkündigungszyklen und parallel betriebenen Versionen während der Migrationszeiträume. Das sieht nach Aufwand aus, erspart aber die Notfallsitzungen, wenn Kunden nach einer ungeplanten Änderung plötzlich nicht mehr an ihre Daten kommen.

Genauso gehört Monitoring dazu. Eine API ohne Beobachtung ist wie eine Straße ohne Verkehrszählung, man weiß weder, wer sie nutzt, noch wo es klemmt. API-Gateways mit integriertem Analytics, Rate-Limiting und Fehler-Tracking sind heute Standard und werden bei API-First-Projekten von Anfang an eingeplant.

Der pragmatische Einstieg im Mittelstand

API-First bedeutet nicht, bestehende Systeme sofort umzubauen. Der vernünftige Weg beginnt bei den Neuentwicklungen, die konsequent API-First angegangen werden. Bestehende Systeme bekommen bei der nächsten größeren Überarbeitung eine API-Schicht. Und Altsysteme ohne eigene Schnittstelle lassen sich über Adapter anbinden, ohne den Legacy-Code anzufassen. Das ist inkrementell, machbar und liefert schnell ersten Nutzen.

API-First ist 2026 keine Architektur für Innovatoren mehr, sondern der Standard. Wer noch nicht dort ist, sollte nicht mehr fragen, ob er wechselt, sondern wann und wie.

Sie möchten eine API-First-Strategie für Ihre Software entwickeln oder bestehende Systeme mit einer sauberen API-Schicht versehen?
Ich helfe Ihnen bei Design, Implementierung und Dokumentation zukunftssicherer API-Architekturen.

Jetzt anfragen →

← Zurück zum Blog

DevOps & Infrastruktur

Observability statt Monitoring: Wie KI-gestütztes System-Debugging die DevOps-Praxis verändert

Monitoring beantwortet die Frage, ob das System läuft. Observability beantwortet die Frage, warum es gerade nicht läuft. Das klingt nach einer Nuance. In verteilten Systemen mit Dutzenden Microservices, mehreren Teams und hunderten Abhängigkeiten ist es der Unterschied zwischen einer Diagnose in fünfzehn Minuten und einem Produktionsausfall von drei Stunden. Mehr als ein Drittel der Organisationen plant in diesem Jahr über eine Million Euro für Observability-Werkzeuge auszugeben, und das aus gutem Grund. Der Nutzen lässt sich in gesenkter Mean Time to Resolution direkt messen.

Die drei Säulen der Observability

Observability stützt sich auf drei Datentypen, die erst zusammen ein vollständiges Bild ergeben. Logs sind zeitgestempelte Ereignisse aus Anwendung und Infrastruktur. Isoliert betrachtet helfen sie in verteilten Systemen wenig, denn ein Fehler in einem Service kann durch eine Kaskade von Ereignissen in drei anderen ausgelöst worden sein. Ohne Korrelation sieht man nur die Symptome. Strukturierte Logs im JSON-Format sind die Voraussetzung dafür, dass sich Ereignisse überhaupt maschinell auswerten und verknüpfen lassen.

Metriken sind aggregierte Messungen über die Zeit, also CPU-Auslastung, Latenz, Fehlerrate oder Durchsatz. Sie eignen sich gut für Dashboards und Alarme, sagen aber nicht, warum ein Wert aus dem Ruder läuft. Ein CPU-Spike ist sichtbar. Ob dahinter ein ineffizienter Algorithmus, ein Traffic-Anstieg oder ein Speicherleck steckt, verraten Metriken allein nicht.

Den Schlüssel zu verteilten Systemen liefern die Traces. Ein Trace verfolgt eine einzelne Anfrage durch alle beteiligten Services, von der eingehenden HTTP-Anfrage bis zu der Datenbankabfrage, die 400 Millisekunden zu lang braucht. Mit OpenTelemetry gibt es dafür einen offenen Standard, den alle großen Plattformen unterstützen.

Mit KI vom Alarm zur Ursache

Die nächste Stufe ist der Einsatz von KI auf diesen Daten. Klassisches Monitoring erzeugt Alarme, oft zu viele und oft zu vage. KI-gestützte Systeme korrelieren Auffälligkeiten über alle drei Datensäulen hinweg, identifizieren wahrscheinliche Ursachen und priorisieren die Handlungsempfehlungen. Statt hundert Alarmen bekommt das Bereitschaftsteam fünf priorisierte Diagnosen mit Kontext.

Ein schönes Beispiel ist die Anomalie-Erkennung. Klassisches Monitoring braucht feste Schwellenwerte, etwa einen Alarm bei mehr als 80 Prozent CPU. Das Problem daran ist, dass derselbe Wert für einen Service normal und für einen anderen kritisch sein kann. KI-basierte Anomalie-Erkennung lernt stattdessen das individuelle Verhaltensmuster jedes Services und meldet sich, wenn ein Muster signifikant abweicht. Das bedeutet weniger Fehlalarme und eine frühere Erkennung echter Probleme.

Auch die Ursachenanalyse selbst wird zunehmend automatisiert. Plattformen wie Dynatrace Davis oder Datadog Watchdog analysieren Incident-Daten und liefern Hypothesen zur Ursache. Den erfahrenen DevOps-Ingenieur ersetzt das nicht, aber es halbiert die Zeit, bis er auf der richtigen Spur ist.

Der pragmatische Einstieg für KMU

Enterprise-Stacks mit fünf Werkzeugen und hohen Monatslizenzen sind für die meisten kleinen und mittleren Unternehmen nicht das Ziel. Der vernünftige Einstieg besteht darin, OpenTelemetry in die Anwendung zu integrieren. Das ist einmalige Arbeit in einem herstellerneutralen, offenen Format. Danach wählt man eine Plattform, etwa Grafana mit Prometheus als selbst gehostete Open-Source-Lösung oder ein SaaS-Angebot mit KMU-freundlichen Tarifen.

Entscheidend ist am Ende ohnehin nicht das Werkzeug, sondern die Disziplin. Sinnvolle Logs strukturiert schreiben, Traces von Anfang an instrumentieren und Dashboards bauen, die echte Fragen beantworten statt nur Graphen zu zeigen. Wer das konsequent tut, verkürzt die Zeit bis zur Problemdiagnose und senkt die Kosten ungeplanter Ausfälle.

Observability ist keine Investition der Kategorie nice to have. In Systemen, die Kundenprozesse tragen, ist die Alternative ein Blindflug. Und Blindflüge enden selten gut.

Sie möchten Observability in Ihre Anwendungen integrieren oder Ihre bestehende Monitoring-Infrastruktur auf den nächsten Level bringen?
Ich helfe Ihnen bei der Auswahl des richtigen Stacks und der praktischen Implementierung.

Jetzt anfragen →

← Zurück zum Blog

IT-Sicherheit & Compliance

Cyber Resilience Act: Warum die Meldepflichten ab September 2026 auch kleine Softwarehersteller treffen

Mit dem Cyber Resilience Act regelt die EU zum ersten Mal die Sicherheit von Produkten mit digitalen Elementen. Das klingt abstrakt, wird aber schnell konkret. Während NIS2 vorschreibt, wie Unternehmen ihre eigene IT absichern müssen, geht es beim CRA um die Software und die vernetzten Geräte, die man verkauft. Die erste harte Frist steht kurz bevor. Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen in ihren Produkten melden.

Betroffen sind mehr Unternehmen, als man denkt

Der CRA gilt für alle Produkte mit digitalen Elementen, die kommerziell in der EU angeboten werden. Das trifft nicht nur die großen Softwarehäuser. Auch der Maschinenbauer, der seine Anlage mit einer eigenen Steuerungssoftware ausliefert, ist im Sinne der Verordnung ein Hersteller. Genauso das mittelständische Unternehmen, das eine Branchenlösung verkauft, die vor fünfzehn Jahren in Delphi oder C# entstanden ist und seitdem gepflegt wird.

Wichtig ist die Abgrenzung zur Auftragsentwicklung. Wer Software ausschließlich für den internen Gebrauch eines einzelnen Kunden entwickelt, fällt in der Regel nicht unter den CRA. Sobald ein Produkt aber am Markt angeboten wird, greifen die Pflichten. Und zwar auch für Bestandsprodukte, denn bei den Meldepflichten zählt nicht, wann ein Produkt auf den Markt kam, sondern ob es noch verkauft und betrieben wird.

Was ab dem 11. September konkret verlangt wird

Die erste Stufe des CRA dreht sich um das Melden von Sicherheitsvorfällen. Wird eine Schwachstelle in einem Produkt aktiv ausgenutzt, muss der Hersteller innerhalb von 24 Stunden eine Frühwarnung an die europäische Sicherheitsbehörde ENISA und das zuständige nationale CSIRT schicken. Eine Kurzmeldung genügt zunächst. Innerhalb von 72 Stunden folgt dann eine ausführlichere Meldung mit einer Bewertung der Schwachstelle, den betroffenen Produkten und den ergriffenen Gegenmaßnahmen. Nach spätestens 14 Tagen wird ein Abschlussbericht fällig, bei größeren Vorfällen nach einem Monat.

Diese Fristen haben es in sich. Sie setzen nämlich voraus, dass ein Unternehmen überhaupt in der Lage ist, Schwachstellen in den eigenen Produkten zu erkennen und einzuordnen. Genau daran scheitert es in der Praxis am häufigsten. Wer keine Übersicht darüber hat, welche Komponenten und Bibliotheken in den eigenen Produkten stecken, kann unmöglich binnen 24 Stunden reagieren.

Die volle Compliance kommt Ende 2027

Ab Dezember 2027 gelten dann die übrigen Pflichten des CRA. Dazu gehören Security by Design über den gesamten Produktlebenszyklus, regelmäßige Sicherheitsupdates und eine sogenannte Software Bill of Materials, also ein maschinenlesbares Inventar aller verwendeten Komponenten. Hinzu kommen Konformitätsbewertung und CE-Kennzeichnung. Bei Verstößen drohen Bußgelder bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes.

Besonders kritisch sind veraltete Abhängigkeiten. Wer Bibliotheken oder Frameworks einsetzt, für die es keine Sicherheitsupdates mehr gibt, kann seine Update-Pflicht strukturell nicht erfüllen. Für viele gewachsene Anwendungen ist der CRA damit der konkrete Anlass, das Thema Modernisierung endlich anzugehen. Nicht als Kür, sondern als Voraussetzung, um das Produkt weiter verkaufen zu dürfen.

Wo man sinnvollerweise anfängt

Am Anfang steht die Frage, ob man überhaupt betroffen ist. Verkaufen Sie Software oder vernetzte Produkte in der EU? Falls ja, folgt die Inventur. Welche Bibliotheken, Frameworks und Laufzeitumgebungen stecken in Ihren Produkten, und werden sie noch gepflegt? Danach braucht es einen definierten Meldeprozess. Es muss klar sein, wer im Unternehmen von einer Schwachstelle erfährt, wer sie bewertet und wer die Meldung an die Behörden übernimmt. Und schließlich stellt sich die Frage der Update-Fähigkeit, also ob Sie für alle Produkte am Markt zeitnah Sicherheitsupdates bauen und verteilen können.

Wer diese Fragen heute nicht beantworten kann, hat bis September Handlungsbedarf. Die Grundlagen dafür sind allerdings keine Raketenwissenschaft. Ein Komponenten-Inventar, eine saubere Build-Pipeline und ein funktionierender Update-Mechanismus sind solide Ingenieursarbeit, die sich in überschaubarer Zeit umsetzen lässt. Und sie zahlen sich unabhängig vom CRA aus, weil sie Produktqualität und Wartbarkeit direkt verbessern.

Sie sind unsicher, ob Ihre Produkte unter den CRA fallen, oder Ihnen fehlen SBOM, Update-Prozesse und Meldefähigkeit?
Ich unterstütze Sie bei der Analyse und der praktischen Umsetzung.

Jetzt anfragen →

← Zurück zum Blog

Recht & Compliance

EU Data Act: Ab September 2026 müssen vernetzte Produkte ihre Daten herausgeben

Wem gehören eigentlich die Daten, die eine vernetzte Maschine, ein Fahrzeug oder ein smartes Gerät erzeugt? Bisher lautete die faktische Antwort meist, dass sie dem Hersteller gehören, denn nur er kam an sie heran. Der EU Data Act ändert das grundlegend. Ab dem 12. September 2026 müssen neu in Verkehr gebrachte vernetzte Produkte so konstruiert sein, dass Nutzer auf die erzeugten Daten direkt, einfach und kostenlos zugreifen können. Die Verordnung nennt das Zugang by Design.

Was der Data Act verlangt

Anwendbar ist der Data Act bereits seit September 2025. Die Stufe, die jetzt im September greift, betrifft die Produktgestaltung selbst. Vernetzte Produkte und die dazugehörigen digitalen Dienste müssen Nutzerdaten standardmäßig zugänglich machen, und zwar maschinenlesbar, strukturiert und möglichst direkt am Produkt oder über eine Schnittstelle. Nutzer haben außerdem das Recht, die Weitergabe ihrer Daten an Dritte zu verlangen, zum Beispiel an einen unabhängigen Wartungsdienstleister statt an den Service des Herstellers.

Parallel dazu arbeitet der deutsche Gesetzgeber gerade am Durchführungsgesetz, das die Durchsetzung regelt. Im Entwurf stehen Bußgelder von bis zu 500.000 Euro pro Verstoß, als zuständige Behörde ist die Bundesnetzagentur vorgesehen.

Wen es trifft und wen nicht

Betroffen sind Hersteller vernetzter Produkte, die in der EU verkauft werden, sowie Anbieter der damit verbundenen digitalen Dienste. Für den deutschen Mittelstand heißt das vor allem Maschinen- und Anlagenbauer, Gerätehersteller mit IoT-Funktionen und Anbieter von Telematik-, Mess- oder Steuerungslösungen. Es gibt zwar eine Ausnahme für Kleinst- und Kleinunternehmen mit weniger als 50 Mitarbeitern und unter 10 Millionen Euro Jahresumsatz. Sie gilt allerdings nicht, wenn das Unternehmen wirtschaftlich mit einem größeren verbunden ist oder als Auftragsfertiger für ein betroffenes Unternehmen arbeitet. Schon die Frage, ob man überhaupt betroffen ist, verdient deshalb eine saubere Prüfung.

Was Zugang by Design technisch bedeutet

In der Umsetzung beginnt alles mit einer Bestandsaufnahme der Daten. Man muss wissen, was das eigene Produkt überhaupt erzeugt, von den Rohdaten der Sensorik über aufbereitete Betriebsdaten bis zu Metadaten. Der Data Act verlangt, dass Nutzer schon vor dem Kauf über Art, Umfang und Zugriffsmöglichkeiten informiert werden. Ohne einen sauber dokumentierten Datenkatalog ist das nicht zu leisten.

Der Kern der Umsetzung ist dann die eigentliche Zugriffsmöglichkeit. Je nach Produkt kann das eine lokale Exportfunktion sein, eine REST-API oder ein kontinuierlicher Datenstrom. Bewährt haben sich offene Formate wie JSON oder CSV, dokumentierte Endpunkte und eine Authentifizierung, die den Nutzer selbst als Berechtigten abbildet und nicht nur den Hersteller. Wer bereits eine API-Strategie hat, erweitert sie. Wer bisher nur proprietäre Datensilos betreibt, braucht ein Konzept.

Dazu kommt das Zusammenspiel mit dem Datenschutz. Sobald personenbezogene Daten im Spiel sind, gelten Data Act und DSGVO nebeneinander. Das Berechtigungsmodell muss abbilden, wer Nutzer im Sinne des Data Act ist, also Käufer, Mieter oder Leasingnehmer, und welche Daten an Dritte fließen dürfen. Geschäftsgeheimnisse dürfen geschützt werden, aber nur mit konkreter Begründung und nicht pauschal.

Aus der Pflicht eine Chance machen

Ich empfehle bei diesem Thema einen Perspektivwechsel. Dieselbe Schnittstelle, die der Data Act erzwingt, ist die Grundlage für neue Services wie Predictive Maintenance, Kundenportale oder eigene Datenprodukte. Hersteller, die den Datenzugang sauber bauen, erfüllen nicht nur eine Vorschrift, sondern schaffen die technische Basis, um aus Betriebsdaten Geschäft zu machen. Ob der Data Act am Ende Compliance-Kosten verursacht oder eine Investition war, entscheidet sich in der Architektur.

Der Zeitplan ist sportlich, aber machbar. Erst die Betroffenheit klären, dann den Datenkatalog erstellen, die Schnittstelle spezifizieren, umsetzen und dokumentieren. Wer jetzt im Juli beginnt, kann zum Stichtag im September zumindest die neuen Produkte konform ausliefern und den Bestand danach strukturiert nachziehen.

Ihre Produkte brauchen bis September eine Datenexport-Schnittstelle, oder Sie möchten erst einmal klären, ob Sie betroffen sind?
Ich unterstütze Sie von der Analyse bis zur fertigen API.

Jetzt anfragen →

← Zurück zum Blog

Recht & Compliance

Digital Omnibus: Die EU verschiebt zentrale AI-Act-Fristen. Was jetzt wirklich gilt

Ende Juni 2026 hat die EU mit dem sogenannten Digital Omnibus zentrale Fristen des AI Act verschoben. Das Europäische Parlament stimmte Mitte Juni zu, der Rat Ende Juni. Die wichtigste Änderung betrifft die Hochrisiko-Systeme. Deren Pflichten sollten ursprünglich am 2. August 2026 greifen und gelten nun erst ab dem 2. Dezember 2027. Für KI in regulierten Produkten wird es sogar August 2028. Wer gerade mitten in der Compliance-Vorbereitung steckt, fragt sich zu Recht, was jetzt eigentlich noch gilt.

Was sich verschiebt

Verschoben wurden die umfangreichen Anforderungen an Hochrisiko-KI, also Risikomanagement, Datenqualität, technische Dokumentation, menschliche Aufsicht und Konformitätsbewertung. Für Systeme etwa in der Personalauswahl, der Kreditvergabe oder in kritischer Infrastruktur greifen diese Pflichten erst im Dezember 2027. Unternehmen, die solche Systeme entwickeln oder einsetzen, haben damit deutlich mehr Zeit gewonnen.

Was unverändert bleibt

Die Regeln, die seit Februar 2025 gelten, bleiben unberührt. Verbotene KI-Praktiken wie Social Scoring oder manipulative Systeme sind weiterhin verboten. Auch die Pflicht zur KI-Kompetenz besteht fort. Wer KI einsetzt, muss sein Personal entsprechend schulen. Dasselbe gilt für die Governance-Regeln, die seit 2025 für Anbieter von KI-Modellen mit allgemeinem Verwendungszweck bestehen.

Bei den Transparenzpflichten, also der Kennzeichnung von KI-Chatbots, KI-generierten Inhalten und Deepfakes, hat der Digital Omnibus den Zeitplan und technische Details wie die Wasserzeichen-Pflicht angepasst. Wer die Kennzeichnung bereits umgesetzt hat, sollte sie deshalb aber nicht zurückbauen. Sie ist mit wenig Aufwand machbar, entspricht dem, was Nutzer und Aufsicht ohnehin erwarten, und sie wird verpflichtend. Die Verschiebung ändert nichts am Ob, nur am Wann.

Warum die EU verschoben hat

Der offizielle Grund ist schlicht, dass die technischen Standards, gegen die Hochrisiko-Systeme geprüft werden sollen, noch nicht fertig sind. Ohne harmonisierte Normen gibt es keine praktikable Konformitätsbewertung. Dazu kam erheblicher Druck aus der Wirtschaft, die Bürokratielasten und Rechtsunsicherheit kritisierte. Der Digital Omnibus ist Teil eines größeren Pakets, mit dem die EU ihre Digitalregulierung vereinfachen will.

Warum Abwarten trotzdem die falsche Strategie ist

So verständlich der Reflex ist, die Sache erst einmal liegenzulassen, halte ich ihn für einen Fehler. Die Verschiebung betrifft die Pflichten, nicht die Einstufung. Wer ein Hochrisiko-System betreibt, wird es auch 2027 noch tun. Und die Anforderungen an sauberes Datenmanagement, Dokumentation und Nachvollziehbarkeit lassen sich nicht in drei Monaten nachrüsten, wenn die Frist dann tatsächlich näher rückt.

Dazu kommt, dass Kunden und Geschäftspartner heute schon nach KI-Governance fragen, völlig unabhängig von gesetzlichen Fristen. Wer in Ausschreibungen belastbare Antworten geben kann, hat einen Vorteil. Und vieles von dem, was der AI Act verlangt, ist ohnehin gute Ingenieurspraxis. Die Versionierung von Modellen und Prompts, das Logging von KI-Entscheidungen und definierte Punkte, an denen ein Mensch eingreifen kann, zahlen sich in jedem KI-Projekt aus, ganz gleich, was in Brüssel entschieden wird.

Mein Rat für die Praxis

Verschaffen Sie sich zuerst einen Überblick, welche KI-Systeme bei Ihnen im Einsatz sind, ob selbst entwickelt oder eingekauft. Prüfen Sie dann, ob etwas davon in die Hochrisiko-Kategorien fällt. Für die meisten kleinen und mittleren Unternehmen lautet die Antwort nein. Dann bleiben vor allem die Transparenz- und Kompetenzpflichten, und die sind überschaubar. Falls doch ein Hochrisiko-System dabei ist, nutzen Sie die gewonnene Zeit bis Ende 2027 für ein strukturiertes Projekt statt für eine hektische Nachrüstung kurz vor knapp. Die Grundlagen wie Kennzeichnung, Schulung und Dokumentation würde ich in jedem Fall jetzt sauber umsetzen.

Dieser Beitrag ersetzt die Fristenangaben in unserem Artikel vom 5. Juli zum EU AI Act, der die Rechtslage vor dem Digital Omnibus beschrieb.

Sie wollen wissen, wie Ihre KI-Systeme einzustufen sind und welche Pflichten für Sie konkret gelten?
Ich helfe Ihnen bei der Bestandsaufnahme und der technischen Umsetzung, von der Kennzeichnung bis zum Logging.

Jetzt anfragen →

← Zurück zum Blog

Webentwicklung & Recht

BFSG-Abmahnwelle 2026: Ist Ihre Website barrierefrei genug?

Das Barrierefreiheitsstärkungsgesetz gilt seit dem 28. Juni 2025, und spätestens seit Ende letzten Jahres zeigt sich, dass es kein zahnloses Gesetz ist. Die Zahl der Abmahnungen wegen fehlender Barrierefreiheit steigt deutlich, und Fachleute rechnen für die zweite Jahreshälfte 2026 mit automatisierten Massenprüfungen durch spezialisierte Kanzleien. Eine Abmahnung kostet schnell einen drei- bis vierstelligen Betrag, im Wiederholungsfall drohen Bußgelder bis 100.000 Euro. Die gute Nachricht ist, dass die häufigsten Mängel rein technischer Natur sind und sich systematisch beheben lassen.

Wer überhaupt betroffen ist

Das BFSG betrifft Unternehmen, die digitale Dienstleistungen für Verbraucher anbieten, also vor allem Onlineshops, Buchungs- und Terminsysteme, Banking und Ticketing. Eine reine Firmen-Visitenkarte ohne Bestell- oder Buchungsfunktion fällt in der Regel nicht darunter. Kleinstunternehmen mit weniger als zehn Mitarbeitern und unter zwei Millionen Euro Umsatz sind bei Dienstleistungen ausgenommen. Genau diese Ausnahme sorgt allerdings für viel Unsicherheit, denn sie gilt nicht für Produkte und schützt in Grenzfällen auch nicht vor wettbewerbsrechtlichen Abmahnungen. Im Zweifel lohnt sich die Prüfung.

Woran Websites am häufigsten scheitern

An erster Stelle stehen fehlende oder nutzlose Alternativtexte. Jedes informative Bild braucht einen Alt-Text, der den Inhalt tatsächlich beschreibt. Ein Dateiname wie bild1.jpg hilft niemandem weiter. Rein dekorative Bilder bekommen ein leeres alt-Attribut, damit Screenreader sie überspringen. Das ist der am einfachsten zu behebende und zugleich am häufigsten abgemahnte Mangel.

Dahinter folgen unzureichende Farbkontraste. Text muss sich ausreichend vom Hintergrund abheben, die WCAG verlangt für normalen Text ein Kontrastverhältnis von mindestens 4,5 zu 1. Der hellgraue Text auf weißem Grund, den man in vielen modernen Designs sieht, fällt da durch. Die Prüfung ist mit kostenlosen Tools in Minuten erledigt, die Behebung meist eine überschaubare CSS-Anpassung.

Deutlich mehr Arbeit steckt in der Tastaturbedienung. Alle Funktionen einer Website müssen ohne Maus nutzbar sein, von der Navigation über Formulare bis zum Warenkorb. Typische Fehler sind Menüs, die nur auf Mausberührung reagieren, Buttons aus div-Elementen ohne Fokus-Handling und Overlays, aus denen man per Tastatur nicht mehr herauskommt. Hier geht es an die Struktur des Frontends, und genau deshalb wird dieser Punkt gern aufgeschoben.

Auch Formulare sind ein Dauerbrenner. Eingabefelder brauchen programmatisch verknüpfte Beschriftungen, und Fehlermeldungen müssen als solche erkennbar und verständlich sein. Ein Placeholder-Text ersetzt kein Label, denn er verschwindet beim Tippen. Und schließlich fehlt erstaunlich oft die Barrierefreiheitserklärung. Betroffene Anbieter müssen sie veröffentlichen, ihr Fehlen ist trivial festzustellen und deshalb ein beliebter Abmahngrund.

Systematisch vorgehen statt punktuell flicken

Der sinnvolle Weg ist ein Audit entlang der einschlägigen Normen, also EN 301 549 beziehungsweise WCAG 2.1 AA. Automatisierte Prüfwerkzeuge finden erfahrungsgemäß nur einen Teil der Probleme, deshalb gehört eine manuelle Prüfung mit Tastatur und Screenreader dazu. Danach wird priorisiert behoben, zuerst die abmahnrelevanten und nutzerkritischen Punkte, dann der Rest. Wenn das einmal sauber gemacht ist, wird Barrierefreiheit Teil der normalen Qualitätssicherung bei jedem Release und verursacht kaum noch Zusatzaufwand.

Ein Nebeneffekt wird dabei oft unterschätzt. Barrierefreie Websites sind besser strukturiert, schneller und für Suchmaschinen besser lesbar. Saubere Überschriftenhierarchien, beschriftete Bilder und semantisches HTML sind genau das, was auch Google und die neuen KI-Suchsysteme belohnen. Die Investition zahlt also doppelt ein.

Sie möchten wissen, wie barrierefrei Ihre Website oder Ihr Shop wirklich ist, bevor es ein Abmahnanwalt prüft?
Ich biete Ihnen ein technisches Barrierefreiheits-Audit mit priorisierter Mängelliste und setze die Behebung auf Wunsch direkt um.

Jetzt anfragen →

← Zurück zum Blog

Digitalisierung

E-Rechnungspflicht ab 2027: Warum 2026 das entscheidende Jahr für Ihre Rechnungsprozesse ist

Seit Januar 2025 müssen Unternehmen in Deutschland E-Rechnungen empfangen können. Das haben die meisten inzwischen gelöst. Die eigentliche Herausforderung kommt jetzt, denn am 31. Dezember 2026 endet die Übergangsfrist für den Versand. Ab dem 1. Januar 2027 müssen Unternehmen mit mehr als 800.000 Euro Vorjahresumsatz im Geschäft mit anderen Unternehmen strukturierte elektronische Rechnungen ausstellen. Ein PDF per E-Mail zählt dann nicht mehr. Wer seine Rechnungsprozesse dieses Jahr nicht umstellt, riskiert ab 2027 formal unwirksame Rechnungen, im schlimmsten Fall mit Folgen für den Vorsteuerabzug des Kunden.

Was eine E-Rechnung ist und was nicht

Eine E-Rechnung im Sinne des Gesetzes ist ein strukturierter Datensatz nach der europäischen Norm EN 16931, den eine Software automatisch verarbeiten kann. In Deutschland haben sich dafür zwei Formate etabliert. Die XRechnung ist ein reines XML-Format, das ursprünglich für Rechnungen an Behörden entwickelt wurde. Maschinen lesen es perfekt, Menschen ohne passende Software gar nicht. ZUGFeRD geht einen anderen Weg und bettet die strukturierten XML-Daten in eine normale PDF-Rechnung ein. Der Mensch sieht das gewohnte Dokument, die Software liest die Daten. Für viele Mittelständler ist das der pragmatische Weg, weil bestehende Abläufe weiterlaufen können. Wichtig ist dabei, dass nur die Profile ab EN-16931-Konformität die gesetzlichen Anforderungen erfüllen.

Beide Formate sind zulässig. Entscheidend ist, dass die eigenen Systeme sie korrekt erzeugen, validieren und die Anforderungen der Empfänger erfüllen.

Das eigentliche Problem sind die Altsysteme

Eine Rechnung entsteht selten im luftleeren Raum. Sie kommt aus der Warenwirtschaft, dem ERP oder einer selbst entwickelten Branchenlösung. Und genau da liegt bei vielen Mittelständlern das Problem. Gewachsene Systeme, oft vor zehn oder zwanzig Jahren in Delphi, VB oder C# entwickelt, erzeugen Rechnungen als Druckausgabe oder PDF, aber keine EN-16931-konformen Datensätze. Der ursprüngliche Hersteller existiert nicht mehr, der Quellcode liegt brach oder das nötige Modul-Update wird schlicht nicht mehr angeboten. Solche Konstellationen sehe ich in meiner Arbeit regelmäßig.

Realistisch gibt es drei Lösungswege. Wenn Quellcode und Know-how verfügbar sind, lässt sich das Bestandssystem um ein Exportmodul für XRechnung und ZUGFeRD erweitern. Das ist solide Entwicklungsarbeit mit überschaubarem Umfang. Alternativ kann eine vorgeschaltete Konverter-Lösung die vorhandenen Rechnungsdaten aus der Datenbank oder aus Exportdateien in konforme Formate wandeln und validieren. Der dritte Weg ist der Umstieg auf neue Software. Er ist der sauberste, aber auch der teuerste und langwierigste, und allein wegen der E-Rechnung lohnt er sich selten.

Validierung und Archivierung nicht vergessen

Mit dem Erzeugen ist es nicht getan. Ausgehende Rechnungen sollten gegen die Norm validiert werden, bevor sie das Haus verlassen, denn fehlerhafte Datensätze führen zu Rückläufern und Zahlungsverzögerungen. Außerdem müssen E-Rechnungen GoBD-konform archiviert werden, und zwar im strukturierten Originalformat und nicht nur als PDF-Ansicht. Wer Empfang, Erzeugung, Validierung und Archiv von Anfang an als einen zusammenhängenden Prozess denkt, erspart sich spätere Nacharbeiten.

Der Zeitplan für den Rest des Jahres

Bis zum Sommer sollte die Bestandsaufnahme stehen. Welches System erzeugt Ihre Rechnungen, was kann es schon, was fehlt? Bis zum Herbst sollte der Lösungsweg feststehen und umgesetzt sein, ob Modul, Konverter oder Migration. Das vierte Quartal gehört dann dem Testlauf mit echten Kunden und der Validierung, damit ab Januar nichts klemmt. Für Unternehmen unter 800.000 Euro Umsatz gilt die Versandpflicht übrigens erst ein Jahr später ab 2028. Empfang und Archivierung gelten aber längst für alle.

Unterm Strich ist die E-Rechnung weniger ein Steuerthema als ein Software- und Schnittstellenthema. Und sie ist eine Gelegenheit. Wer ohnehin an seine Rechnungsprozesse muss, kann Medienbrüche, manuelle Übertragungen und Insellösungen gleich mit beseitigen.

Ihr ERP- oder Warenwirtschaftssystem kann noch keine XRechnung oder ZUGFeRD?
Ich entwickle Exportmodule und Konverter-Lösungen für Bestandssysteme, auch für Delphi- und andere Legacy-Anwendungen.

Jetzt anfragen →

← Zurück zum Blog

KI-Integration

KI ohne Cloud: Wann sich lokale Sprachmodelle im Mittelstand wirklich lohnen

Unsere Daten dürfen nicht in die US-Cloud. Diesen Satz höre ich in fast jedem Gespräch über KI-Projekte im Mittelstand, und er hat in diesem Jahr mehr Gewicht denn je. Laut Bitkom halten 85 Prozent der deutschen Unternehmen Deutschland für zu abhängig von US-Cloud-Anbietern, fast zwei Drittel überdenken gerade ihre Cloud-Strategie. Gleichzeitig sind Open-Source-Sprachmodelle und die Werkzeuge für ihren Betrieb so reif wie nie. Zeit für eine nüchterne Betrachtung, wann sich der Betrieb eigener Sprachmodelle lohnt und wann nicht.

Was lokale Modelle heute können

Offene Modelle wie Llama, Mistral oder Qwen erreichen bei vielen praxisrelevanten Aufgaben ein Niveau, das für den Unternehmenseinsatz völlig ausreicht. Dokumente zusammenfassen, E-Mails klassifizieren, Informationen aus Texten ziehen oder interne Wissensbestände per RAG durchsuchbar machen funktioniert damit zuverlässig. Werkzeuge wie Ollama oder vLLM haben den Betrieb auf eigener Hardware vom Forschungsvorhaben zum kalkulierbaren Standardprojekt gemacht.

Ehrlich muss man bei den Grenzen bleiben. Die Spitzenmodelle der großen Anbieter sind bei komplexem Schlussfolgern, anspruchsvoller Codegenerierung und schwierigen Randfällen weiterhin deutlich besser. Ein lokal betriebenes Modell mit acht Milliarden Parametern ersetzt kein Frontier-Modell. Es ist ein anderes Werkzeug für andere Aufgaben, und wer das von Anfang an so einordnet, wird nicht enttäuscht.

Die Kostenrechnung

Cloud-APIs rechnen pro verarbeitetem Token ab und sind bei geringem Volumen konkurrenzlos günstig. Die Gleichung kippt bei hohem, gleichmäßigem Durchsatz. Wer täglich zehntausende Dokumente klassifiziert oder eine interne Suche mit vielen Anfragen betreibt, zahlt in der Cloud schnell vierstellige Monatsbeträge. Ein Server mit einer aktuellen Workstation-GPU kostet in der Anschaffung einen mittleren vierstelligen Betrag und verarbeitet solche Lasten lokal, danach fallen im Wesentlichen Stromkosten an.

Zur ehrlichen Gesamtrechnung gehört allerdings mehr als die Hardware. Einrichtung, Modell-Updates, Monitoring und Ausfallsicherheit liegen beim eigenen Betrieb in der eigenen Verantwortung, die sonst der Cloud-Anbieter trägt. Als Faustregel aus meinen Projekten: Unter einem dauerhaften, planbaren Grundvolumen lohnt sich eigene Hardware selten. Darüber wird sie schnell attraktiv, besonders wenn der Datenschutz ohnehin gegen die Cloud spricht.

Der eigentliche Treiber heißt Datenschutz

Für viele Branchen ist die Kostenfrage ohnehin zweitrangig. Arztpraxen und Gesundheitsdienstleister, Kanzleien, Personalabteilungen oder Unternehmen mit sensiblen Konstruktions- und Kundendaten wollen oder dürfen bestimmte Daten schlicht nicht an externe Dienste geben. Beim lokalen Betrieb verlassen die Daten das Haus nicht. Es gibt keine Auftragsverarbeitung bei einem Drittanbieter, keinen Drittlandtransfer und keine Abhängigkeit von der aktuellen Rechtslage zwischen EU und USA. Die datenschutzrechtliche Bewertung wird dramatisch einfacher, wenn es keinen externen Empfänger gibt.

Dazu kommt eine strategische Ebene, die oft übersehen wird. Ein lokales Modell kann nicht abgekündigt, umbepreist oder in seinen Nutzungsbedingungen geändert werden. Wer schon einmal erlebt hat, wie ein Cloud-Modell in Rente geschickt wird und eine Migration erzwingt, versteht den Wert dieser Kontrolle.

In der Praxis fährt man meist hybrid

Ein striktes Entweder-oder bewährt sich selten. Sinnvoller ist eine Aufgabenteilung, bei der sensible und hochvolumige Standardaufgaben lokal laufen, etwa Klassifikation, Extraktion und die interne Suche über Firmendokumente, während anspruchsvolle und seltene Aufgaben ohne sensible Daten an ein Frontier-Modell per API gehen. Eine sauber gebaute Abstraktionsschicht in der eigenen Software macht das Routing pro Aufgabe konfigurierbar und hält den Wechsel zwischen Modellen trivial.

Der Einstieg muss kein Großprojekt sein

Ich empfehle, mit einem Pilotprojekt und einem klar umrissenen Anwendungsfall zu starten. Das kann ein RAG-System über die interne Dokumentation sein, ein Klassifikator für den E-Mail-Eingang oder eine Zusammenfassungsfunktion für Berichte. Dafür reicht anfangs gemietete oder vorhandene Hardware, und gemessen wird an echten Aufgaben mit echten Daten. Erst wenn Qualität und Volumen stimmen, folgt die Investition in eigene Infrastruktur. So bleibt das Risiko klein, und die Entscheidung fällt auf Basis von Fakten statt Anbieterfolien.

Sie überlegen, ob lokale KI für Ihr Unternehmen sinnvoll ist, oder suchen jemanden, der ein RAG-System on-premise umsetzt?
Ich berate Sie unabhängig und entwickle die Lösung, die zu Ihren Daten und Ihrem Budget passt.

Jetzt anfragen →

← Zurück zum Blog

Über mich

Wer entwickelt Ihre Lösung?

Kein anonymes Team, kein Projektmanager - ich bin Ihr direkter Ansprechpartner, Entwickler und Berater in einer Person.

Andreas Frank - Softwareentwickler Freiburg
Verfügbar für neue Projekte
StandortFreiburg i.Br.
TätigkeitFreiberuflich
Seit2009
SprachenDE / EN
USt-IdNr.DE453427455

Andreas Frank

Softwareentwickler & KI-Integrationsspezialist

Freiburg im Breisgau, Baden-Württemberg

Über 15 Jahre Erfahrung in der Softwareentwicklung - als Entwickler, Teamleiter, Abteilungsleiter und zuletzt als Engineering Manager, wo ich ein Entwicklungsteam von bis zu 18 Mitarbeitern geleitet habe. Seit 2024 bringe ich dieses Wissen als Freelancer direkt in Ihre Projekte ein.

Mein Schwerpunkt liegt auf der Verbindung von bewährter Unternehmenssoftware mit modernen KI-Möglichkeiten. Ich modernisiere Delphi-Anwendungen, integriere KI-Agenten in bestehende Prozesse und entwickle maßgeschneiderte Lösungen - immer mit dem Ziel, echten Nutzen zu schaffen statt technologischen Selbstzweck zu betreiben.

Was ich an meiner Arbeit schätze: Die Probleme sind real, die Wirkung ist messbar, und die Kunden kommen wieder. Das ist mein Qualitätsmaßstab.

Primäre Technologien

DelphiC# / .NETPythonKI-AgentenRAG-SystemeOpenAI / ClaudeMSSQLMySQLSybasePostgreSQLREST APIsAndroid / JavaNext.js / PHPDockerGit

Direkt & persönlich

Sie sprechen immer mit mir - keine Zwischenebene, kein Vertrieb.

Praxisorientiert

Lösungen, die im Alltag funktionieren - nicht im Demo-Modus.

Technisch sauber

Code, der wartbar ist und auf dem Sie in Jahren noch aufbauen können.

DSGVO-konform

Datenschutz ist für mich kein Anhang, sondern Teil des Designs.

2009

Fachinformatiker & Entwickler

Ausbildung zum Fachinformatiker Systemintegration und Einstieg als Softwareentwickler in der Sozialwirtschaftssoftware-Branche.

2016

Teamleiter → Abteilungsleiter

Fachliche und disziplinarische Führung einer Entwicklungsabteilung mit bis zu 18 Mitarbeitern in den Teams Desktop-DEV, Mobile-DEV, Requirements Engineering, Testing und Reporting.

2021

Engineering Manager

Leitung eines Entwicklungsteams mit bis zu 18 Mitarbeitern in der Pflegemanagement-Software-Branche.

2024

Freiberuflich

Direkter Einsatz von über 15 Jahren Praxiserfahrung als Freelancer für KMU im deutschsprachigen Raum.

Lassen Sie uns Ihr Projekt besprechen.

Kostenloses Erstgespräch - direkt mit mir, kein Umweg.

Jetzt Kontakt aufnehmen →

Kontakt

Sprechen wir über Ihr Projekt.

Kostenloses Erstgespräch, direkt mit mir. Keine Warteliste, kein Vertriebsteam.

Telefon

+49 1520 98 21 769

E-Mail

info@frank-development.com

Adresse

Else-Wagner-Str. 12, 79115 Freiburg

Meine Zusage

Ich antworte auf jede Anfrage persönlich - werktags innerhalb von 24 Stunden. Sie bekommen keine Vorlage, sondern eine ehrliche Einschätzung zu Ihrem Projekt.

* Pflichtfelder. Ihre Daten werden nur zur Bearbeitung Ihrer Anfrage genutzt. Datenschutz

Standort

Freiburg im Breisgau

Persönliche Treffen sind in Freiburg und der Region Südbaden jederzeit möglich. Remote-Projekte führe ich für Kunden im gesamten deutschsprachigen Raum durch.

Andreas FrankElse-Wagner-Straße 12
79115 Freiburg im Breisgau
Deutschland

Karte wird nur auf Anfrage geladen (Datenschutz).

Rechtliches

Impressum

Rechtliches

Datenschutzerklärung