Forschungszulage für Software & KI: Was ist förderfähig (und was nicht)?

Fast jedes Tech-Team sagt: “Wir machen R&D.” Die BSFZ fragt eher: “Erzeugt ihr neues technisches Wissen – oder baut ihr ‘nur’ ein Produkt?” Gerade bei Software & KI ist die Grenze wichtig, weil viele Tätigkeiten zwar wertvoll sind, aber nicht automatisch F&E im Sinne der Forschungszulage.

Der Kern: Woran die BSFZ bei Software-Projekten glaubt (oder zweifelt)

Damit Softwareentwicklung als F&E gilt, müssen typischerweise 3 Dinge klar werden:

1) Neuartigkeit: Was ist wirklich neu?

Nicht: “Wir nutzen LLMs / bauen eine App.” Sondern: “Wir entwickeln Methode X, weil Standardansatz Y unter Randbedingung Z scheitert.”

2) Technische Ungewissheit: Was ist unklar, bevor ihr startet?

Beispiele:

• Latenz / Skalierung / Datenqualität verhindert Standardlösung

• Modellgenauigkeit unter realen Bedingungen unklar

• robuste Generalisierung bei Domain-Shift

• Echtzeit-Optimierung unter harten Constraints

3) Planmäßigkeit: Wie testet/validiert ihr systematisch?

• Hypothesen → Experimente → Ergebnisse → Iteration

• Benchmarking / Tests / Reproduzierbarkeit

• Arbeitspakete (und was “Done” heißt)

Förderfähige Beispiele (typisch)

Hier sind Muster, die oft gut passen (wenn sauber beschrieben):

KI/ML

• Entwicklung neuer Modellarchitektur/Ensembling für eure Domäne

• Verfahren zur robusten Anomalieerkennung bei seltenen Events

• Data-centric AI: neue Pipeline zur Label-Qualitätssicherung, die Standardtools nicht abdecken

• On-device / Edge-Inference unter extremen Ressourcenlimits

Data/Algorithmik/Optimization

• neuartige Forecasting-Methodik für volatile Nachfrage in Supply Chains

• Multi-Objective Optimization (Kosten/Lieferzeit/CO2) mit neuem Lösungsansatz

• Echtzeit-Scheduling/Dispatching mit harten Restriktionen

Systems/Infra

• eigene Kompression, Streaming, Caching-Strategien wegen spezieller Datenformen

• neue Sicherheits-/Privacy-Methoden für sensible Datenverarbeitung

• deterministische Deployments/Observability für ML-Systeme in regulated environments

Nicht förderfähig (die häufigsten Missverständnisse)

Viele Teams verlieren Förderung, weil sie “alles reinwerfen”. Typische Nicht-F&E-Bestandteile sind u. a.:

• Marketing/Sales, Website-Anpassungen, Markteinführung

• Customer Support / Betrieb eines Produktivsystems

• Erstellung von Doku/Handbüchern/Schulungsmaterial, Preislisten etc. 

Achtung: Das heißt nicht “Projekt tot” – sondern Scope trennen.

So schreibst du einen BSFZ-tauglichen Software-Antrag (Template)

Wenn du eine Projektbeschreibung schreibst, mach es so konkret wie möglich:

(1) Ziel / Wissenslücke

• Welche technische Lücke wollt ihr schließen?

• Was kann der Stand der Technik nicht?

(2) Ausgangslage / Stand der Technik

• Welche Methoden habt ihr geprüft? Warum reichen sie nicht?

(3) Ungewissheiten / Risiken

• Welche Parameter sind unsicher?

• Was kann schiefgehen?

(4) Lösungsweg (Arbeitspakete)

• Datenerhebung/-aufbereitung

• Modell-/Algorithmusentwicklung

• Prototyping

• Test/Validierung (z. B. Benchmarks, Offline/Online Tests)

• Iterationen

(5) Ergebnis & Messkriterien

• Welche technischen KPIs beweisen Erfolg?

Pro-Tipp: Die BSFZ hat auf ihrer Seite sogar Beispielanträge und Hinweise, wie “gut” vs. “schlecht” formuliert ist.

Bonus: Warum Software-Projekte oft unterschätzt werden

Viele Softwareteams dokumentieren (verständlicherweise) “Produktfeatures”. Für die Forschungszulage musst du “Technikfortschritt” dokumentieren. Heißt praktisch: Ihr braucht kein 80-Seiten-Papier – aber ihr braucht eine saubere Story über Neuheit, Ungewissheit, Plan.