In diesem Beitrag
Softwarebeschaffung 2027: Nachweise vor Launch oder Verlängerung
Kläre vor einem Softwarekauf für 2027 zuerst, welches Produkt, welcher KI-Einsatz und welcher Cloud-Dienst vorliegen. Fordere dann Nachweise zu den Terminen an, die für deine Rolle gelten: Release- und Schwachstellenunterlagen, KI-Verantwortlichkeiten und Tests sowie Export- und Ausstiegsbedingungen. Jede offene Frage braucht einen internen Verantwortlichen und einen Entscheidungstermin.
Geltungsbereich und Quellen geprüft am 5. November 2026. Dieser Wavect-Ratgeber verbindet die Anbieterauswahl mit technischen Nachweisen. Der Kalender fasst ausgewählte EU-Anforderungen zusammen. Die Beispiele und Projektprüfpunkte sind unsere vorgeschlagene Beschaffungsmethode. Lass die tatsächliche Einstufung und den Vertrag qualifiziert rechtlich prüfen. Ein späterer Termin in einer Verordnung verschiebt keine Pflichten, die nach einer anderen bereits gelten.
Welche Termine 2027 können deinen Softwarekauf beeinflussen?
Führe getrennte Kalendereinträge für Produktsicherheit, Hochrisiko-KI und Cloud-Anbieterwechsel. Bevor du einen Termin als Projektanforderung übernimmst, musst du den jeweiligen Geltungsbereich klären. Die folgenden Daten stammen aus den verlinkten Rechtsvorschriften. Ein Compliance-Siegel des Anbieters ersetzt diese Prüfung nicht.
| Datum | Zu prüfende Anforderung | Folge für die Beschaffung |
|---|---|---|
| 11. September 2026, gilt bereits | Meldepflichten nach Artikel 14 CRA, abhängig vom Geltungsbereich der Verordnung. | Kläre jetzt, wer meldet und wie der Prozess funktioniert. Auf den allgemeinen Geltungsbeginn 2027 zu warten, ergibt noch keinen Meldeprozess. |
| 11. Dezember 2027 | Allgemeiner Geltungsbeginn des Cyber Resilience Act für Produkte in seinem Anwendungsbereich. | Kläre Produkt und Rollen der Wirtschaftsakteure. Fordere vor dem Inverkehrbringen die dafür relevanten Produktsicherheitsnachweise an. |
| 2. Dezember 2027 | Kapitel III Abschnitte 1 bis 3 der KI-Verordnung, ausgenommen Artikel 6 Absatz 5, für Hochrisikosysteme nach Artikel 6 Absatz 2 und Anhang III. | Dokumentiere Verwendungszweck und Einstufung. Kläre, welche Partei die einzelnen benötigten Unterlagen für dieses System liefert. |
| 12. Januar 2027 | Verbot von Wechselentgelten nach Artikel 29 Data Act für erfasste Datenverarbeitungsdienste. | Trenne erfasste Wechselentgelte des Anbieters von Migrationsarbeiten und anderen Vertragsbeträgen. Prüfe die Ausnahmen nach Artikel 31. |
Der CRA mit den Artikeln 69 und 71 regelt Geltungsbeginn und Übergang. Für den operativen Meldeprozess hilft dir der separate Leitfaden zu CRA-Meldungen.
Die aktuelle KI-Verordnung in der konsolidierten Fassung vom 27. Juli 2026, Artikel 113 Buchstabe c sieht für die entsprechenden Hochrisiko-Anforderungen nach Artikel 6 Absatz 1 und Anhang I außerdem den 2. August 2028 vor. Das sind bestimmte Anwendungsdaten für Hochrisikosysteme. Daraus folgt keine allgemeine Verschiebung aller KI-Pflichten. Prüfe die aktuelle Rechtslage vor einer Beauftragung für 2027 erneut.
Der Data Act mit den Artikeln 29 bis 31 unterscheidet Wechselentgelte, andere Gebühren und bestimmte individuell entwickelte Dienste. Artikel 31 Absatz 1 nimmt bestimmte individuell angepasste Dienste, die nicht im Dienstekatalog angeboten werden, von Artikel 29 und weiteren ausdrücklich genannten Vorschriften aus. Damit entfällt nicht pauschal das gesamte Kapitel zum Anbieterwechsel.
Wo musst du Produkt, KI und Cloud zuerst einordnen?
Beschreibe, was du kaufst und wofür du es einsetzen willst. Kläre anschließend mit den rechtlich und technisch Verantwortlichen die jeweiligen Rollen. Individuelle Entwicklung, eine Softwarelizenz und die Verlängerung eines Cloud-Dienstes können innerhalb desselben Projekts unterschiedliche Fragen aufwerfen.
| Kauf | Erste Frage | Angeforderte Nachweise |
|---|---|---|
| Interner Wissensassistent auf einer bestehenden SaaS-Plattform | Welcher KI-Verwendungszweck liegt vor, und welche Partei übernimmt welche Rolle? | Ablaufbeschreibung, Datenflüsse, Zugriffsmodell, Evaluationsergebnisse, Betriebsverantwortung und die einschlägige rechtliche Prüfung. |
| Vernetztes Produkt mit einer notwendigen Komponente zur Fernverarbeitung | Fällt die Lieferung unter Produktdefinition und Geltungsbereich des CRA, und wer ist Hersteller? | Abgrenzung von Produkt und Version, Rollenbewertung, Sicherheitsunterlagen und ein dazu passender dokumentierter Schwachstellenprozess. |
| Cloud-Vertragsverlängerung mit geplantem Anbieterwechsel | Ist der Datenverarbeitungsdienst erfasst, und gilt eine Ausnahme nach Artikel 31? | Leistungsbeschreibung, Exportumfang, vertraglicher Wechselprozess, Aufschlüsselung der Entgelte und eine gegebenenfalls geltend gemachte Ausnahme. |
Die Artikel 2 und 3 CRA bestimmen Geltungsbereich und Produkte, einschließlich relevanter Fernverarbeitungslösungen. Ordne einen SaaS-Kauf nicht allein deshalb als CRA-Produkt ein, weil es um Software geht. Ebenso fällt eine KI-Funktion nicht automatisch in dieselbe Risikokategorie wie eine andere Funktion mit demselben Modell. Dokumentiere den Verwendungszweck, statt eine Einstufung aus einer Produktbezeichnung zu übernehmen.
Welche Nachweise brauchst du vor Unterschrift oder Verlängerung?
Fordere Unterlagen für genau das System und den Release an, die du kaufen willst. Eine brauchbare Antwort nennt die Version, beschreibt die Prüfung und hält offene Punkte fest. Frage, wer diese Nachweise pflegt, wenn sich eine Abhängigkeit, das Betriebsmodell oder der Verwendungszweck ändert.
- Vor der Beauftragung: dokumentierter Geltungsbereich und Rollen, vorgesehene Projektleitung, Abhängigkeiten, Abnahmebedingungen und eine vollständige Aufschlüsselung der Betriebskosten.
- Vor dem Release: vereinbarte Prüfergebnisse, bekannte Fehler, Deployment- und Wiederherstellungsanleitungen sowie die Person, die verbleibende Risiken freigeben darf.
- Vor der Verlängerung: Supportumfang, Änderungen an Produkt und Abhängigkeiten, Exportmöglichkeiten, Übergabebedingungen und eine aktuelle Liste offener Nachweisanfragen.
Bei einem Produkt im CRA-Anwendungsbereich sollten deine Anfragen zur Risikobewertung und technischen Dokumentation des Herstellers nach Artikel 13 passen. Welche Unterlagen und Rechte du bekommst, muss die Beauftragung ausdrücklich klären. Eine interne Pflicht des Anbieters gibt dir nicht automatisch Zugang zu allen internen Dokumenten oder Eigentum am Quellcode.
Unsere Prüfung typischer Klauseln in Softwareangeboten vertieft die Vertragsfragen. Der Ratgeber zur Auswahl einer Softwareagentur hilft dir, Kandidaten anhand desselben Briefings zu vergleichen.
Wie planst du vom Launch rückwärts?
Leite interne Nachweisfristen von deinem tatsächlichen Launch- oder Verlängerungstermin ab. Lass Zeit, um Lücken zu schließen. Die folgende Abfolge mit 90, 60 und 30 Tagen Vorlauf ist ein beispielhafter interner Plan. Daraus folgt weder eine gesetzliche Mindestvorlaufzeit noch die Zusage, dass jedes Projekt in drei Monate passt.
- 90 Tage vor der Entscheidung: Kläre Verwendungszweck und Systemgrenze. Benenne die Verantwortlichen für rechtliche Einstufung und technische Nachweise. Halte Abhängigkeiten bei Zugriff, Beschaffung und Anbieter fest.
- 60 Tage vorher: Prüfe die angebotenen Unterlagen und repräsentative Normal- und Fehlerfälle. Lass den Anbieter fehlende Nachweise erklären und vereinbare einen datierten Plan zum Schließen der Lücken.
- 30 Tage vorher: Erprobe den vereinbarten Wiederherstellungs- oder Exportweg. Kläre kritische offene Punkte, dokumentiere verbleibende Grenzen und entscheide, ob du fortfährst, den Umfang reduzierst oder verschiebst.
Bereits geltende Meldepflichten brauchen jetzt einen funktionierenden Prozess. Darauf hat diese Abfolge keinen aufschiebenden Einfluss. Auch ein spätes Angebot verschiebt keinen gesetzlichen Termin. Kann eine wesentliche Entscheidung nicht rechtzeitig fallen, passe den Vertrags- oder Release-Plan mit den verantwortlichen Personen an.
Wird ein Cloud-Anbieterwechsel 2027 kostenlos?
Bei einem erfassten Anbieter kann die Position für Wechselentgelte nach Artikel 29 auf null fallen. Migrationsaufwand, Parallelbetrieb und sämtliche vertraglichen Verpflichtungen werden dadurch nicht automatisch kostenlos. Kläre Dienst und mögliche Ausnahme nach Artikel 31, bevor du das Entgeltverbot als anwendbar behandelst.
| Kategorie | Angenommener Betrag | Einordnung |
|---|---|---|
| Vom gesetzlichen Verbot erfasstes Wechselentgelt des Anbieters | 0 € | Hier wird die Anwendbarkeit von Artikel 29 nach dem 12. Januar 2027 angenommen. Prüfe diese Annahme. |
| Separat beauftragte Umsetzung der Migration | 4.000 € | Angenommene Entwicklungsarbeit, kein lediglich umbenanntes Wechselentgelt des Anbieters. |
| Parallelbetrieb | 600 € | Angenommene Überschneidung zwischen den beiden Umgebungen. |
| Interner Test- und Abstimmungsaufwand | 900 € | Wirtschaftlicher Wert interner Zeit. Daraus entsteht nicht zwingend eine externe Rechnung oder Auszahlung. |
| Modellierte wirtschaftliche Gesamtkosten | 5.500 € | 4.000 € + 600 € + 900 €, vor Steuern und ohne mögliche Verpflichtungen aus vorzeitiger Kündigung. |
Halte Entgelte wegen vorzeitiger Kündigung und gewöhnliche Dienstleistungsentgelte als eigene Fragen fest. Artikel 29 Absatz 4 unterscheidet diese Kategorien. Lass die tatsächlichen Beträge und Bedingungen prüfen, statt jedes so bezeichnete Entgelt als zulässig anzunehmen. Für die praktische Übergabe hilft dir der Leitfaden zum Wechsel des Softwareanbieters.
Was gehört in das Nachweisregister zur Anbieterentscheidung?
Verknüpfe in einem Register jede Anforderung mit einer verantwortlichen Person und prüfbaren Nachweisen. Kennzeichne den Stand als demonstriert, vertraglich bestätigt, nur öffentlich angeboten oder ungeklärt. Die Begriffe beschreiben deinen Wissensstand. Daraus entstehen weder Anbieterbewertungen noch eine Bestätigung der Rechtskonformität.
Felder zum Übernehmen: System und Version; Verwendungszweck; Rollen- und Geltungsbereichsentscheidung; angeforderter Nachweis; Anbieterdokument oder Quelle; intern verantwortliche Person; gegebenenfalls einschlägige Rechtsvorschrift; interne Frist; offene Frage; Release- oder Verlängerungsentscheidung.
Beispielhafter Eintrag: System/Version: Kundenportal 1.0; Verwendungszweck: Rechnungsabruf; Rolle/Geltungsbereich: rechtliche Prüfung ausstehend; angeforderter Nachweis: Rolle A kann nicht auf die Rechnung von Rolle B zugreifen; Quelle: Testbericht für den Release-Build; Verantwortung: Product Owner; Rechtsverweis: Einordnung ausstehend; interne Frist: vor dem Pilot; offener Punkt: Wiederherstellungstest aus dem Backup; Entscheidung: Pilot ausstehend. Das ist ein vorgeschlagener Datensatz, kein Kundenergebnis. Halte eine kritische offene Frage ausdrücklich fest, statt sie mit sachfremden Nachweisen zu verrechnen.
Unsere veröffentlichte Bond-Analytics-Fallstudie liefert angrenzenden technischen Kontext. Daraus folgt weder ein regulatorisches Ergebnis für 2027 noch eine formale Rechtsberatung. Wavects Technologieberatung kann helfen, technische Entscheidungen und die dafür nötigen Nachweise zu strukturieren. Bring deine geplante Systemgrenze in ein Gespräch zur Eingrenzung deiner Softwarebeschaffung mit.
