Wer ein IoT Gerät entwickeln lässt oder Elektronikentwicklung outsourcen möchte, steht früh vor einer Frage, die technisch versierte Teams oft unterschätzen: Was gehört eigentlich in den Vertrag mit dem Dienstleister? Hardware-Projekte scheitern seltener an der Technologie als an unklaren Absprachen, fehlenden Eskalationswegen oder Eigentumsfragen, die erst dann auftauchen, wenn es zu spät ist. Dieser Artikel zeigt, welche Vertragsklauseln bei IoT-Projekten wirklich entscheidend sind und wo erfahrene Teams regelmäßig Lücken lassen.
Typische Vertragslücken bei IoT-Projekten
IoT-Entwicklungsverträge haben eine spezifische Schwachstelle: Sie werden oft auf Basis von Software-Projektvorlagen erstellt, die für Hardware-Entwicklung strukturell ungeeignet sind. Software-Meilensteine lassen sich rollback-fähig definieren. Ein Schaltungsdesign, das in Produktion gegangen ist, nicht.
Die häufigsten Lücken in der Praxis betreffen drei Bereiche. Erstens fehlt eine klare Abgrenzung zwischen Firmware, Hardware-Design und mechanischen Komponenten, was bei Mängeln zu Zuständigkeitskonflikten führt. Zweitens enthalten viele Verträge keine Regelung für den Fall, dass ein Bauteil während der Entwicklung EOL (End of Life) wird, obwohl Lieferkettenstörungen seit 2021 zum Standardrisiko gehören. Drittens fehlen Regelungen für Zertifizierungsiterationen: Wenn ein Gerät beim ersten CE- oder FCC-Test durchfällt, wer trägt die Kosten für Nachbesserung und Retest? Ohne explizite Klausel entsteht hier regelmäßig Streit.
Leistungsumfang und Spezifikationen klar definieren
Der Leistungsumfang ist das technische Fundament des Vertrags. Eine vage Beschreibung wie „Entwicklung eines BLE-fähigen Sensors“ ist für beide Seiten ein Risiko. Konkret sollte der Vertrag folgende Elemente als Anhang oder separates Dokument enthalten: eine funktionale Spezifikation mit definierten Testkriterien, eine Liste der Zielplattformen (Mikrocontroller-Familie, RTOS falls zutreffend), Kommunikationsprotokolle mit Versionsangabe sowie Umgebungsbedingungen (Temperaturbereich, Schutzklasse, mechanische Anforderungen).
Ein häufiger Fehler: Spezifikationen werden im Laufe des Projekts mündlich erweitert, ohne dass der Vertrag angepasst wird. Das führt dazu, dass der Dienstleister Leistungen erbringt, die nicht vergütet werden, oder der Auftraggeber Leistungen erwartet, die nie vereinbart wurden. Jede Änderung an der Spezifikation sollte schriftlich dokumentiert und mit einer Aufwandsschätzung verknüpft sein.
Akzeptanzkriterien statt Beschreibungen
Statt „das Gerät soll energieeffizient sein“ sollte der Vertrag konkrete Akzeptanzkriterien enthalten: etwa einen definierten Stromverbrauch im Sleep-Mode (z.B. unter 10 µA bei 3,3 V) und eine Mindestakkulaufzeit unter definierten Nutzungsbedingungen. Ohne messbare Kriterien ist die Abnahme subjektiv und damit streitanfällig.
Eigentums- und Lizenzrechte an Hardware und Firmware
Eigentumsrechte sind bei Elektronikentwicklung komplexer als bei reiner Softwareentwicklung, weil mehrere Schutzrechtskategorien gleichzeitig relevant sind: Urheberrecht an der Firmware, Eigentumsrecht an Schaltungsplänen und PCB-Layouts, sowie potenziell Patentrechte an spezifischen Schaltungskonzepten.
Der Standardfall in der Industrie: Der Auftraggeber erhält nach vollständiger Bezahlung das vollständige Eigentumsrecht an allen projektspezifischen Entwicklungsartefakten, einschließlich Quellcode, Schaltplänen, Gerber-Dateien und Stücklisten. Kritisch ist der Umgang mit Vorentwicklungen (sogenannten „Background IP“) des Dienstleisters, also wiederverwendbaren Treiberbibliotheken, HAL-Schichten oder internen Frameworks. Diese bleiben üblicherweise Eigentum des Dienstleisters. Der Vertrag sollte explizit regeln, welche Lizenz der Auftraggeber daran erhält, ob diese Lizenz exklusiv ist, und ob sie auf Dritte übertragbar ist.
Ein konkretes Risiko: Wenn der Firmware-Stack des Dienstleisters proprietäre Middleware enthält und der Vertrag nur eine nicht-übertragbare Nutzungslizenz vorsieht, kann der Auftraggeber die Firmware nicht ohne Weiteres an einen anderen Dienstleister zur Weiterentwicklung übergeben. Das schafft eine Abhängigkeit, die die Verhandlungsposition bei zukünftigen Projekten erheblich schwächt.
Meilensteine, Zahlungsplan und Änderungsmanagement
Ein Zahlungsplan, der sich an Projektmeilensteinen orientiert, schützt beide Seiten. Für den Auftraggeber stellt er sicher, dass Zahlungen an nachweisbare Ergebnisse geknüpft sind. Für den Dienstleister reduziert er das Risiko, bei Projektabbruch auf erbrachten Leistungen sitzen zu bleiben.
Typische Meilensteine auf dem Weg eines IoT Produkts zur Serienreife umfassen: Abschluss der Systemspezifikation, Freigabe des Schaltplans, Lieferung des ersten Hardware-Prototypen (EVT), erfolgreicher Abschluss der Firmware-Basisintegration, DVT-Freigabe nach Validierungstests und schließlich Produktionsfreigabe. Jeder Meilenstein sollte mit einer definierten Abnahmedokumentation verknüpft sein, nicht nur mit einer Datumsangabe.
Change Requests strukturiert handhaben
Änderungsmanagement ist bei Hardware-Projekten kritischer als bei Software, weil Änderungen an Schaltungsdesigns oft Kaskadeneffekte haben: Eine geänderte Spannungsversorgung kann EMI-Verhalten, Zertifizierungsumfang und PCB-Layout gleichzeitig betreffen. Der Vertrag sollte einen formalen Change-Request-Prozess definieren, der Aufwandsschätzung, Auswirkungsanalyse und schriftliche Freigabe vor Umsetzung vorschreibt. Ohne diesen Prozess werden Änderungen häufig informell beauftragt und führen zu Budgetüberschreitungen, die im Nachhinein schwer zu begründen sind.
Geheimhaltung, Haftung und Gewährleistung im Blick behalten
Eine NDA allein reicht für IoT-Projekte nicht aus. Der Geheimhaltungsvertrag sollte explizit technische Unterlagen, Schaltpläne, Stücklisten, Firmware-Architekturen und Produktionsdaten umfassen und eine Rückgabe- oder Löschpflicht nach Projektende definieren.
Bei der Haftung ist die zentrale Frage: Wer haftet für Schäden, die durch Produktmängel entstehen, nachdem das Gerät in Serie gegangen ist? Dienstleister schränken ihre Haftung typischerweise auf den Auftragswert oder auf nachgewiesene Fehler in der vereinbarten Spezifikation ein. Das ist legitim, aber der Auftraggeber sollte sicherstellen, dass grobe Fahrlässigkeit und vorsätzliche Pflichtverletzungen von dieser Begrenzung ausgenommen sind. Für Medizintechnik-Projekte oder sicherheitskritische Embedded-Systeme gelten zusätzliche regulatorische Anforderungen, die im Vertrag adressiert werden sollten.
Gewährleistungsfristen für Hardware-Entwicklungsleistungen sind branchenüblich zwischen 6 und 12 Monaten angesiedelt. Wichtiger als die Frist ist die Definition des Gewährleistungsumfangs: Gilt sie für Designfehler, für Fertigungsfehler, oder für beides? Und wer trägt die Kosten für Nachbesserungen, wenn der Fehler erst nach Serienbeginn entdeckt wird?
Checkliste: Das sollte kein IoT-Vertrag missen
Die folgende Checkliste fasst die kritischen Vertragsbestandteile zusammen, die bei IoT- und Elektronikentwicklungsprojekten regelmäßig fehlen oder unzureichend formuliert sind:
- Technische Spezifikation als Vertragsanhang mit messbaren Akzeptanzkriterien
- Abgrenzung von Background IP und Projekt-IP mit klarer Lizenzdefinition
- Vollständige Eigentumsübertragung aller projektspezifischen Artefakte nach Bezahlung (Quellcode, Schaltpläne, Gerber-Dateien, BOM)
- Meilensteinplan mit Abnahmedokumentation statt reinen Datumsangaben
- Formaler Change-Request-Prozess mit Pflicht zur schriftlichen Freigabe vor Umsetzung
- Regelung für EOL-Bauteile und Lieferkettenstörungen während der Entwicklung
- Zertifizierungsverantwortung mit klarer Regelung für Nachbesserungskosten bei Testversagen
- Haftungsausschluss mit Ausnahmen für grobe Fahrlässigkeit und Vorsatz
- Gewährleistungsumfang mit Unterscheidung zwischen Design- und Fertigungsfehlern
- Geheimhaltungsklausel mit expliziter Rückgabe- oder Löschpflicht für technische Unterlagen
- Regelung bei Projektabbruch: Welche Leistungen werden vergütet, welche Unterlagen werden übergeben?
Ein Vertrag, der diese Punkte abdeckt, reduziert nicht nur das Risiko von Streitigkeiten, sondern schafft auch die Grundlage für eine produktive Zusammenarbeit, in der beide Seiten wissen, was sie voneinander erwarten können.
Wie Oxeltech bei IoT-Vertragsprojekten unterstützt
Wir bei Oxeltech begleiten Kunden nicht nur technisch, sondern auch in der strukturierten Projektvorbereitung. Wer mit uns ein IoT Gerät entwickeln lässt, erhält von Beginn an klare Projektstrukturen, die genau die Vertragspunkte adressieren, die in diesem Artikel beschrieben werden.
- Technische Spezifikation: Wir erarbeiten gemeinsam eine detaillierte Systemspezifikation mit messbaren Akzeptanzkriterien, die als Vertragsgrundlage dient.
- IP-Klarheit: Alle projektspezifischen Entwicklungsartefakte, einschließlich Schaltpläne, Firmware-Quellcode, Gerber-Dateien und Stücklisten, gehen nach Projektabschluss vollständig in das Eigentum des Auftraggebers über.
- Strukturiertes Änderungsmanagement: Jede Änderung an Scope oder Spezifikation wird formal dokumentiert, bewertet und schriftlich freigegeben, bevor sie umgesetzt wird.
- Zertifizierungsbegleitung: Wir unterstützen bei CE, FCC und weiteren regulatorischen Anforderungen und planen Zertifizierungsrisiken von Anfang an in das Projektbudget ein.
- Transparente Meilensteinstruktur: Zahlungen sind an nachweisbare Projektergebnisse geknüpft, nicht an Kalendertermine.
Wenn Sie ein IoT-Produkt entwickeln oder Elektronikentwicklung outsourcen möchten und einen Partner suchen, der technische Exzellenz mit klaren Projektstrukturen verbindet, sprechen Sie uns an. Wir freuen uns auf Ihr Projekt.
Ähnliche Artikel
- Was sind Embedded Systems und wie werden sie eingesetzt?
- Warum ein erfahrener IoT Entwicklungspartner mehr spart als er kostet
- Wie baut man ein eingebettetes System?
- Wann sollte man auf kontinuierliche Vitalwertüberwachung statt auf punktuelle Messung setzen?
- Was ist der Unterschied zwischen einem Wearable-Prototyp und einem Serienprodukt?
