Daten aus SLAs extrahieren
Ein Service Level Agreement legt fest, welche Zusagen ein Anbieter zur Leistungsfähigkeit eines Service macht, und welches Geld fließt, wenn diese Zusagen nicht eingehalten werden. Es tritt neben ein Master Services Agreement, ohne es zu ersetzen: Während ein MSA die Vertragsparteien, das Haftungsregime und die Regelungen zum geistigen Eigentum festlegt und ein Statement of Work die Leistungen und deren Preise bestimmt, legt ein SLA messbare Ziele fest: Verfügbarkeit, Reaktionszeit und Lösungszeit, sowie die Servicegutschriften, die bei Nichterreichen eines Ziels geschuldet werden. Die Menschen, die täglich damit arbeiten, sind der Vendor Operations Lead, der monatlich dagegen berichtet, das Procurement-Team des Kunden, das die Gutschriften verhandelt hat, und der Incident Manager, der im Moment eines Ausfalls darauf zugreift. Präzision steckt in den Zahlen und dem Zeitraum, über den sie gemessen werden. Ein Hosting-SLA garantiert vielleicht 99,9 % monatliche Verfügbarkeit, was in einem Monat mit 30 Tagen etwa 43 Minuten Ausfallzeit erlaubt, ein Reaktionsziel von 30 Minuten für einen Priority-1-Vorfall und ein Lösungsziel von 4 Stunden, jeweils gemessen pro Kalendermonat. Fällt die Verfügbarkeit in eine Bandbreite, ist eine Servicegutschrift fällig: 10 % der monatlichen Gebühr zwischen 99,0 % und 99,9 %, 25 % zwischen 95,0 % und 99,0 % und 50 % unter 95,0 %, wobei die Gutschriften gedeckelt sind, sodass die Gesamthaftung für einen Monat 50 % der Monatsgebühr nicht überschreiten kann. Ausschlüsse bestimmen, was nicht gegen das Ziel zählt: geplante Wartungsfenster, höhere Gewalt und Ausfallzeiten, die durch die eigene Konfiguration des Kunden verursacht wurden, sodass derselbe Ausfall ein SLA verletzen kann und ein anderes nicht. Talonic liest das SLA und gibt Anbieter und Empfänger, Beginn- und Ablaufdatum, die Verfügbarkeits- und Zeitziele sowie die Strafenstruktur als Felder aus, während die Service Levels, die Strafen und die Ausschlüsse als Tabellen erhalten bleiben. Richten Sie es auf ein Cloud-Hosting-SLA vom 2026-07-01 zwischen der Halcyon Cloud Services GmbH als Anbieter und der Meridian Retail AG als Empfänger, das 99,9 % Verfügbarkeit in einem monatlichen Zeitfenster gegen eine monatliche Gebühr von 40.000 EUR garantiert, und die Ziele, die Gutschrift-Bandbreiten und die Haftungsobergrenze von 20.000 EUR werden als Felder statt als Klauseln in ein Vendor-Management-System geladen. Erfasst, wie geschrieben, enthalten die Bedingungen keine Bewertung darüber, ob eine Gutschrift geschuldet ist oder ob die Vereinbarung durchsetzbar ist.
Was aus SLAs extrahiert wird
So funktioniert die Extraktion für SLAs
SLAs kommen als Anlage zu einem MSA, als eigenständiges unterschriebenes PDF oder als Export aus einem Vendor-Portal, und die Ziele und Gutschriften stehen in Tabellen, deren Spalten von Anbieter zu Anbieter wechseln. Talonic klassifiziert das Dokument und ordnet es dem Vertragsschema in der Field Registry zu, deren Klauselsatz der CUAD-Taxonomie folgt, sodass das Verfügbarkeitsziel, die Reaktions- und Lösungszeiten, der Messzeitraum und die Strafbedingungen jeweils einem eigenen Feld zugeordnet werden. Die Service Levels werden als Tabelle mit Metrik-Typ, Zielwert, Einheit und Messzeitraum ausgegeben, die Strafen als Tabelle mit Verletzungsschwelle, Gutschriftart, Betrag und maximaler Haftung pro Zeitraum, und die Ausschlüsse als eigene Tabelle, sodass geplante Wartung und höhere Gewalt erkennbar sind statt verborgen zu bleiben. Das Verfügbarkeitsziel wird als Zahl typisiert, und die Servicegutschrift-Bandbreiten werden gegen die monatliche Gebühr geprüft, sodass eine Gutschrift von 10 % auf eine Gebühr von 40.000 EUR als 4.000 EUR verifiziert statt einfach übernommen wird. Jeder Wert trägt einen Konfidenzwert und einen Verweis auf seine Quellregion in Übereinstimmung mit DIN SPEC 91491, sodass ein Leser aus Einkauf oder Betrieb eine Gutschrift-Bandbreite bis zur Klausel zurückverfolgen kann, aus der sie stammt. So ausgegeben, wie geschrieben, überlassen die Verpflichtungen die Frage, ob eine Vertragsverletzung eingetreten ist, den Parteien.
Beispielextraktion
Ein Managed-Cloud-Hosting-SLA als Anlage zu einem MSA
{
"document_number": "SLA-2026-0417",
"document_date": "2026-06-24",
"effective_date": "2026-07-01",
"expiration_date": "2027-06-30",
"service_provider.name": "Halcyon Cloud Services GmbH",
"service_recipient.name": "Meridian Retail AG",
"service_description": "Managed cloud hosting and 24x7 incident support for the Meridian ecommerce platform",
"uptime_percentage": 99.9,
"response_time": "30 minutes for Priority 1 incidents",
"resolution_time": "4 hours for Priority 1 incidents",
"measurement_period": "Calendar month",
"penalty_type": "service_credit",
"penalty_amount": 4000,
"penalty_currency": "EUR",
"cap_on_liability": "50% of the monthly service fee, being 20,000 EUR",
"governing_law": "Federal Republic of Germany",
"escalation_contact": "noc@halcyoncloud.example, +49 30 5550 1180",
"renewal_term": "Auto-renews for successive 12 month terms unless 60 days notice is given",
"service_levels": [
{
"metric_type": "Availability",
"metric_value": "99.9",
"measurement_unit": "percent",
"measurement_period": "Monthly"
},
{
"metric_type": "Response time (P1)",
"metric_value": "30",
"measurement_unit": "minutes",
"measurement_period": "Per incident"
},
{
"metric_type": "Resolution time (P1)",
"metric_value": "4",
"measurement_unit": "hours",
"measurement_period": "Per incident"
}
],
"penalties": [
{
"breach_threshold": "Availability 99.0% to 99.9%",
"penalty_type": "service_credit",
"penalty_amount": 4000,
"penalty_currency": "EUR",
"maximum_liability": "20,000 EUR per month"
},
{
"breach_threshold": "Availability 95.0% to 99.0%",
"penalty_type": "service_credit",
"penalty_amount": 10000,
"penalty_currency": "EUR",
"maximum_liability": "20,000 EUR per month"
},
{
"breach_threshold": "Availability below 95.0%",
"penalty_type": "service_credit",
"penalty_amount": 20000,
"penalty_currency": "EUR",
"maximum_liability": "20,000 EUR per month"
}
],
"exclusions": [
{
"exclusion_type": "Scheduled maintenance",
"exclusion_description": "Downtime during the announced Sunday 02:00 to 06:00 CET maintenance window"
},
{
"exclusion_type": "Force majeure",
"exclusion_description": "Events beyond the reasonable control of the provider"
},
{
"exclusion_type": "Customer-caused",
"exclusion_description": "Downtime resulting from customer configuration changes or third-party integrations"
}
]
}Häufig gestellte Fragen
Wie unterscheidet sich ein SLA vom MSA und SOW, zu dem es gehört?
Ein MSA legt die Rahmenbedingungen und die Haftungsregelung fest, ein Statement of Work legt die Leistungen und deren Preise fest, während ein SLA die messbaren Servicelevel-Ziele und die bei Nichteinhaltung fälligen Gutschriften festlegt. Talonic liest alle drei anhand des Contract-Schemas und hält ihre jeweiligen Felder getrennt, sodass das Verfügbarkeitsziel nicht mit dem Leistungsplan vermischt wird.
Werden die Service-Credit-Stufen mit der Gebühr abgeglichen?
Ja. Das Verfügbarkeitsziel wird als Zahl typisiert, und jede Credit-Stufe wird gegen die monatliche Gebühr geprüft. So wird verifiziert, dass ein 10%-Credit bei einer monatlichen Gebühr von 40.000 EUR 4.000 EUR entspricht und die 50%-Obergrenze 20.000 EUR entspricht.
Welche Ausschlüsse werden erfasst?
Die Ausschlusstabelle gibt jedes ausgeschlossene Ereignis mit seiner Beschreibung zurück, sodass geplante Wartungsfenster, höhere Gewalt und durch die Kundenkonfiguration verursachte Ausfallzeiten von den Ereignissen getrennt werden, die auf das Verfügbarkeitsziel angerechnet werden.
Entscheidet Talonic, ob ein Service-Credit geschuldet ist?
Nein. Talonic gibt die Ziele, den Messzeitraum, die Credit-Stufen und die Ausschlüsse wie geschrieben zurück und verknüpft jedes mit seiner Quellregion. Ob ein bestimmter Ausfall das Ziel verletzt hat und ob daher ein Credit zu zahlen ist, ist eine Berechnung der Parteien, nicht der Extraktion.
Bereit, Daten aus Ihrem eigenen SLAs zu extrahieren?
Autorenhinweis
Geprüft von Talonic engineering, contract schema review · zuletzt geprüft am 2026-07-08