Die Dienstleistungsschicht als Systemeigenschaft. Warum die Richtung eines Enterprise-KI-Partners mehr zählt als die Ankündigung.

In den sechzig Tagen zwischen Anfang Mai und Anfang Juli 2026 haben fünf der größten KI-Anbieter der Welt – Microsoft, OpenAI, Anthropic, Amazon und Meta – gleichzeitig groß angelegte Programme für eingebettetes Engineering gestartet, die auf europäische und nordamerikanische Unternehmen abzielen. Microsoft Frontier Company, 2,5 Milliarden US-Dollar und sechstausend Ingenieure, angekündigt am 2. Juli. OpenAIs Frontier und Frontier Alliances, im selben Zeitraum formalisiert mit McKinsey, Boston Consulting Group, Accenture, Capgemini, Amazon Web Services, Databricks und Snowflake. Anthropics Joint Venture über 1,5 Milliarden Dollar, unterstützt von Blackstone, Hellman & Friedman und Goldman Sachs, gegründet am 4. Mai mit Fokus auf mittelständische Unternehmen. Amazons paralleles Engagement über eine Milliarde Dollar am 30. Juni. Metas Enterprise Solutions-Einheit, laut Naomi Gleits internem Memo, strukturiert rund um Produktmanager, Dateningenieure und Softwareingenieure, die direkt in Kundenorganisationen eingebettet sind. Fünf Anbieter, fünf verschiedene Strukturen, fünf verschiedene Kapitalquellen. Eine Richtung: Die Frontier-Labs und die größten Hyperscaler werden gleichzeitig und offen zu Dienstleistungsunternehmen. Sie bauen diese Dienstleistungsunternehmen außerdem – und das ist die wichtigere Beobachtung – vom Modell nach außen auf. Das ist genau die falsche Richtung, aus der heraus man ein Dienstleistungsunternehmen für europäische Unternehmen aufbaut. neuland.ai wurde aus der anderen Richtung aufgebaut, und der Unterschied ist bedeutsamer, als er auf den ersten Blick erscheinen mag.

Dies ist der zwölfte Beitrag einer Reihe, die ich für neuland.ai schreibe. [¹] Der rote Faden durch jeden Beitrag ist derselbe: Im Enterprise-KI-Bereich liegen der Wert, das Risiko und der Burggraben in der Schicht über und um das Modell herum – nicht im Modell selbst. Dieser Beitrag erweitert dieses Argument um eine weitere Ebene im Stack – zur Dienstleistungsschicht selbst, dazu, wie ein Dienstleistungspartner aufgebaut wird, und dazu, was diese Richtung über den architektonischen Rückstand bestimmt, der in der Organisation des Kunden verbleibt, sobald das Engagement endet.

Was die Labs und Hyperscaler richtig gemacht haben

Vor der strukturellen Beobachtung zunächst das Lob. Die Frontier-Labs und die Hyperscaler haben den Markt richtig gelesen, und die Diagnose hinter ihrem Schwenk zu eingebetteten Dienstleistungen ist inhaltlich korrekt.

Der PYMNTS Enterprise AI Benchmark Report, im Juni veröffentlicht und auf Befragungen von Führungskräften in Unternehmen mit mindestens einer Milliarde US-Dollar Jahresumsatz basierend, ergab, dass einundsiebzig Prozent die organisatorische Bereitschaft – nicht die Technologie selbst – als primäre Barriere für KI-Leistung identifizierten. Nur elf Prozent nannten die Technologie. [²] Die empirischen Belege sind konsistent. Uber hat sein gesamtes KI-Budget für 2026 innerhalb der ersten vier Monate des Geschäftsjahres aufgebraucht. Starbucks hat sein KI-Inventarsystem nach neun Monaten eingestellt. Keine dieser Geschichten handelt von einem schlechten Modell; beide sind Geschichten über Deployments, die nie die Lücke von „Technologie vorhanden" zu „Wert in der Produktion" überbrückt haben. Stellenausschreibungen für Forward-Deployed Engineers – eine Kategorie, die vor achtzehn Monaten kaum existierte – stiegen zwischen Januar und September 2025 allein um mehr als achthundert Prozent. [³]

Aus diesem Muster haben die Frontier-Labs und Hyperscaler die richtige Schlussfolgerung gezogen: Ihre Kunden brauchen nicht in erster Linie bessere Modelle. Ihre Kunden brauchen Hilfe dabei, die Modelle, auf die sie bereits Zugriff haben, in produktiven Betrieb innerhalb ihrer tatsächlichen Unternehmen zu bringen. Das ist ein Dienstleistungsproblem, und die Labs und Hyperscaler treten mit acht Milliarden US-Dollar an gebundener Embedded-Engineering-Kapazität in dieses Problem ein, weil die Diagnose stimmt.

Hinter der Diagnose steckt eine kommerzielle Logik, die es wert ist, direkt angesprochen zu werden. Der Zugang zu Frontier-Modellen wird zur Ware. GLM-5.2, Mitte Juni unter der MIT-Lizenz veröffentlicht, liegt auf dem härtesten öffentlich verfügbaren Coding-Benchmark bei etwa einem Prozentpunkt hinter Claude Opus 4.8 – zu ungefähr einem Sechstel der Token-Kosten. [⁴] Der Abstand zwischen proprietärer Frontier-Veröffentlichung und Open-Weight-Äquivalent hat sich auf rund sieben Monate an der Frontier verengt und ist bei der Mehrzahl der Enterprise-Workloads erheblich geringer. In einer Welt, in der der Modellzugang nicht mehr der Ort ist, an dem die Anbietermarge liegt, muss die Marge irgendwohin wandern. Die Labs und Hyperscaler haben unabhängig voneinander und gleichzeitig entschieden, dass sie in Dienstleistungen wandert. Das ist ein legitimer Schritt, und es gibt Unternehmen, für die die daraus resultierenden Engagements echten Nutzen bringen werden.

Die Beobachtung, um die es in diesem Beitrag geht, liegt eine Ebene unterhalb der Diagnose. Sie betrifft nicht die Frage, ob die Labs und Hyperscaler zu Recht in Dienstleistungen eintreten – das tun sie –, sondern die Richtung, aus der sie eintreten.

Richtung bestimmt, was ein Dienstleistungsunternehmen produzieren kann

Ein Dienstleistungsunternehmen, das vom Modell nach außen aufgebaut wird, ist eine grundlegend andere Art von Dienstleistungsunternehmen als eines, das vom Kunden nach innen aufgebaut wird, und der Unterschied bestimmt, was jedes davon produzieren kann.

Wenn ein Frontier-Lab oder ein Hyperscaler einen Dienstleistungsarm aufbaut, kommen seine Ingenieure bei jedem Kundenengagement mit tiefem Fachwissen über die Plattform an, die ihr Unternehmen gebaut hat. Anthropics eingebettete Ingenieure kennen das Anthropic-Modellportfolio, die Anthropic-Tool-Call-Oberfläche, die Anthropic-Evaluierungsrahmen. OpenAIs kennen ihr Äquivalent innerhalb ihrer eigenen Plattform. Microsofts Frontier Company-Ingenieure kommen mit Kenntnissen von Microsoft Foundry, Microsoft IQ, Microsoft Agent 365, Microsoft Agent Framework, Microsoft Execution Containers und wissen, wie diese Komponenten innerhalb eines Microsoft 365-Tenants auf Azure zusammenpassen. Das ist keine Kritik an den beteiligten Ingenieuren – sie sind ausgezeichnet in dem, was sie wissen, und was sie wissen, ist genau das, was ihr Unternehmen jahrelang aufgebaut hat. Es ist eine Beschreibung der Form des Fachwissens.

Die Konsequenz ist eindeutig. Ein Embedded-Engineering-Engagement, das von einem Frontier-Lab oder einem Hyperscaler durchgeführt wird, baut gegen die Plattform, die seine Ingenieure kennen. Es kann kaum anders sein. Der Stack, den der Kunde am Ende des Engagements erbt, ist unvermeidlich und konstruktionsbedingt durch die Plattform geprägt, von der die Ingenieure kamen. Die Sprache der Modellvielfalt in den Launch-Ankündigungen ist auf der Marketingebene real – Microsoft Frontier Companys Positionierung nennt explizit OpenAI, Anthropic, Microsoft AI, Open-Source- und spezialisierte Branchenmodelle –, aber die operative Realität eines zwölfmonatigen eingebetteten Engagements ist, dass die Ingenieure auf das zurückgreifen werden, was sie kennen, das optimieren werden, was sie kennen, und einen Stack hinterlassen werden, der widerspiegelt, was sie kennen.

Das ist bedeutsam, weil die Wahl des eingebetteten Dienstleistungspartners im Jahr 2026 eine architektonische Entscheidung mit mehrjährigen Konsequenzen ist, die das Engagement selbst überdauern. Die Engagements, die in Q3 und Q4 unterzeichnet werden, werden die KI-Architektur europäischer Unternehmen bis zum Ende des Jahrzehnts prägen. Die Kunden, die das vor der Unterzeichnung verstehen, werden sich achtzehn bis vierundzwanzig Monate von jetzt an in einer materiell anderen Position befinden als die Kunden, die es erst danach verstehen.

neuland.ai wurde aus der anderen Richtung aufgebaut

neuland.ai begann nicht als Plattformunternehmen. Es begann, mehrere Jahre bevor generative KI für Enterprise-Workloads produktionstauglich wurde, als Dienstleistungsunternehmen. Wir haben End-to-End-KI-Anwendungsfälle für regulierte DACH-Kunden in den Bereichen Rechtsdienstleistungen, Finanzdienstleistungen, Fertigung, öffentlicher Sektor und Gesundheitswesen aufgebaut – zu einer Zeit, als die Sprachmodelle, mit denen wir arbeiten mussten, die Arbeit allein nicht zuverlässig genug für regulierte Unternehmensprozesse erledigen konnten. Das Engineering-Problem jener Ära war anders als das, über das der aktuelle Markt spricht. Es gab keine Orchestrierungsframeworks zu übernehmen, keine Ontologie-Schichten zu lizenzieren, noch kein MCP-Protokoll, keine etablierten Muster, um ein Modell gegen das eigene Korpus eines Kunden zu verankern. Jedes Engagement war im Grunde eine maßgeschneiderte Lösung für das, was sich im Laufe der Zeit, über Engagements hinweg, als dasselbe wiederkehrende architektonische Problem darunter herausstellte. Wie bringt man nicht-deterministische generative Ausgaben dazu, sich innerhalb eines deterministischen Geschäftsprozesses zu verhalten, integriert mit den echten Daten des Kunden, unter echten Compliance-Anforderungen, auf einem Zuverlässigkeitsniveau, gegen das ein reguliertes europäisches Unternehmen tatsächlich operieren kann?

Der neuland.ai HUB ist das, was aus dieser Erfahrung entstanden ist. Es ist keine Plattform, die wir auf einem Whiteboard entworfen haben und dann auf der Suche nach Kunden waren, an die wir sie verkaufen konnten. Es ist die produktisierte Form der Muster, die sich immer wieder, über Jahre der tatsächlichen Arbeit innerhalb echter Unternehmen, wiederholt haben. Jede Fähigkeit, die in der öffentlichen Plattformarchitektur dokumentiert ist, ist dort, weil wir sie in einem spezifischen Kundenengagement benötigten, bevor sie als produktisiertes Feature existierte. Der deterministische oder agentische Orchestrator entstand, weil verschiedene Kunden-Workflows verschiedene Orchestrierungsmodi erforderten. Die rekursiven Sprachmodell-Threads und das Multi-Hop-Reasoning-Fabric entstanden, weil komplexe regulierte Workflows Dekompositionsstrategien erforderten, die kein Single-Shot-Prompt liefern konnte. Die automatisch generierte Ontologie-Schicht entstand, weil die Verankerung eines Agenten gegen das echte Entitätsmodell eines Kunden – das Vokabular seiner Verträge, seiner Lieferantenhierarchien, seiner Prozessausnahmen – sich als der wichtigste Einzelfaktor dafür herausstellte, ob das Deployment nützliche Ausgaben produzierte. Die Petabyte-skaligen Ingestion-Pipelines entstanden, weil echte Enterprise-Korpora groß, multimodal und unordentlich sind und kein gehostetes Anbieter-API-Preismodell den Kontakt mit einem ernsthaften Dokumentenbestand übersteht. Die hyperscaler-unabhängige Deployment-Topologie entstand, weil DACH-Kunden zu Recht die Option wollten, auf Infrastruktur zu laufen, die sie kontrollierten. [⁵]

Die Richtung ist der Punkt. neuland.ais Ingenieure kommen nicht mit dem besten Wissen über ein bestimmtes Modell, einen bestimmten Hyperscaler oder ein bestimmtes Orchestrierungsframework zu einem Kundenengagement. Unser Fachwissen ist die Umgebung des Kunden – das SAP- oder S/4HANA-System, das den operativen Kern betreibt, die Dateiserver und Dokumentenmanagementsysteme, die institutionelles Wissen enthalten, die branchenspezifische Ontologie, die kodiert, wie das Unternehmen tatsächlich funktioniert, das Compliance-Büro, das genehmigt, was automatisiert werden kann, der Regulierer, der das Ergebnis prüft. Der HUB ist darauf ausgelegt, in diese Umgebung zu passen. Die Modellschicht ist konstruktionsbedingt agnostisch, weil sie aufgebaut wurde, bevor irgendein einzelnes Modell die Antwort war, und für Kunden, deren Bedürfnisse über Branchen hinweg so weit variierten, dass kein einzelnes Modell jemals die Antwort sein würde.

Was diese Richtung produziert

Die praktischen Unterschiede zeigen sich an drei Stellen, und jede ist es wert, explizit benannt zu werden.

Der erste ist Modellneutralität. Wenn ein neues Frontier-Modell veröffentlicht wird und unsere DSGVO-Konformitätsbewertung gegen echte Kunden-Workloads besteht, tritt es in die Routing-Tabelle ein. Wenn ein Open-Weight-Arbeitspferd für eine Kategorie von Workloads wirtschaftlich vorzuziehen ist – Mistral Large 3 selbst gehostet für einen Dokumentenverarbeitungs-Workflow, Aleph Alpha Pharia 7B für einen deutschsprachigen regulierten Workflow, GLM-5.2 selbst gehostet, wo die Lizenzierungs- und Souveränitätshaltung es erlauben – aktualisiert sich die Routing-Tabelle. Der Stack des Kunden muss nicht neu aufgebaut werden, um all das zu berücksichtigen. Modellneutralität ist für uns kein Marketingversprechen. Es ist eine strukturelle Eigenschaft einer Plattform, die nie um ein bestimmtes Modell herum aufgebaut wurde, weil keines der verfügbaren Modelle beim Start des Aufbaus allein ausreichend war.

Der zweite ist die Haltung des Dienstleistungsengagements. Die Dienstleistungsunternehmen der Frontier-Labs sind strukturell darauf ausgerichtet, die Plattform des Labs in die Umgebung des Kunden einzuführen. Das ist die kommerzielle Logik, die das Engagement rechtfertigt. Unsere Engagements sind um eine völlig andere Ausrichtung strukturiert. Wir versuchen nicht, die bestehenden Systeme des Kunden zu umgehen, seinen SaaS-Stack zu ersetzen oder ihn in neue Tools einzusperren. Wir versuchen, neben dem zu passen, was der Kunde bereits betreibt – sein Verbündeter bei der Arbeit zu sein, Enterprise-KI tatsächlich innerhalb eines Unternehmens zum Laufen zu bringen, das bereits SAP hat, das bereits Dateiserver hat, das bereits ein branchenspezifisches Compliance-Framework hat, das bereits Geschäftsmethoden hat, die Jahrzehnte zu entwickeln brauchten. Die interessanteste Engineering-Arbeit in jedem Engagement findet nach unserer Erfahrung an den Nahtstellen zwischen dem HUB und allem statt, was der Kunde bereits hat. Die bestehende operative Architektur des Kunden zu respektieren ist kein Nice-to-have. Es ist eine Voraussetzung dafür, etwas Nützliches darauf aufzubauen.

Der dritte Unterschied ist, was der Kunde am Ende besitzt. Ein neuland-Engagement hinterlässt dem Kunden eine HUB-Instanz auf dem Substrat, das der Kunde gewählt hat – standardmäßig STACKIT oder On-Premises, Private Cloud oder Hybrid, wo der Workload es erfordert –, verankert auf einer Ontologie, die aus den eigenen Daten des Kunden abgeleitet wurde, integriert mit Modellanbietern, die der Kunde austauschen kann, unter dem eigenen Policy-Framework des Kunden verwaltet und von den eigenen Teams des Kunden mit unserer Unterstützung nach Bedarf betrieben. Der Rückstand des Engagements gehört dem Kunden, nicht uns. Wenn wir ein Engagement abschließen, ist der KI-Stack des Kunden nicht abhängiger von neuland als zuvor. In vielen Fällen ist er es weniger, weil die Plattform die internen Teams des Kunden befähigt, die KI-Fähigkeit selbst zu betreiben.

Persönliche Einschätzung

Die Embedded-Engineering-Programme der Frontier-Labs werden gute Engagements produzieren. Einige Unternehmen werden echten Nutzen daraus ziehen, und in manchen Situationen wird es die richtige Antwort sein, 2,5 Milliarden US-Dollar an eingebetteten Ingenieuren in das Gebäude eines Kunden zu schicken, um gegen die Plattform eines bestimmten Anbieters zu bauen. Dieser Beitrag ist keine Empfehlung, dass europäische Unternehmen diese Engagements kategorisch ablehnen. Es ist eine Empfehlung, dass die Richtung, aus der der Dienstleistungspartner kam, mehr bedeutet als die Entscheidungen, die innerhalb des Engagements getroffen werden – und dass die Richtung es wert ist, in der Beschaffung explizit gemacht zu werden, bevor das Engagement unterzeichnet wird.

Der Rückstand eines Engagements, das vom Modell nach außen aufgebaut wurde, ist ein Stack, dessen architektonische Entscheidungen das Modell begünstigen. Der Rückstand eines Engagements, das vom Unternehmen nach innen aufgebaut wurde, ist ein Stack, dessen architektonische Entscheidungen das Unternehmen begünstigen. Beides ist legitim. Beides produziert echte Arbeit in echten Kundenumgebungen. Aber achtzehn bis vierundzwanzig Monate nach dem Ende des Engagements – beim nächsten Mal, wenn ein Frontier-Modell durch eine Exportkontrollrichtlinie zurückgerufen wird, beim nächsten Mal, wenn ein Hyperscaler sein Preismodell für einen kritischen Inferenz-Workload ändert, beim nächsten Mal, wenn der Regulierer eine Frage zur jurisdiktionellen Datenübertragung stellt, die der Kunde selbst beantworten muss – wird die Richtung in der Antwort sichtbar sein, die der Kunde geben kann, ohne einen Dienstleistungsvertrag wieder öffnen zu müssen, um Hilfe bei der Beantwortung zu erhalten.

Die acht Milliarden US-Dollar an Embedded-Engineering-Kapazität, die nun über Microsoft Frontier Company, OpenAI Frontier, Anthropics Joint Venture, Amazons paralleles Engagement und Metas Enterprise Solutions-Einheit verteilt werden, sind das wichtigste Marktsignal seit dem Beginn der Kommoditisierung der Modellschicht. Richtig gelesen, ist es auch das eigene Eingeständnis der Frontier-Labs – ausgedrückt durch Kapitalallokation statt durch Aussagen –, dass das Argument dieser Reihe in den vergangenen zehn Monaten inhaltlich korrekt war. Modellzugang ist nicht der Burggraben. Integration ist es. Ontologie ist es. Governance ist es. Delivery ist es. Die Labs haben identifiziert, wohin der Wert gewandert ist, und sie setzen Kapital ein, um dorthin zu gelangen. neuland.ai ist seit dem Zeitpunkt, bevor die Frontier-Modelle allein ausreichend waren, in dieser Schicht des Stacks tätig, weil dort die Arbeit war und wo die Arbeit noch immer ist. Die Richtung, aus der wir zum aktuellen Moment gekommen sind, ist anders als die Richtung, aus der die Labs kommen, und dieser Unterschied ist der Kern dessen, was wir anbieten.

Die Dienstleistungsschicht ist eine Systemeigenschaft. Was diese Eigenschaft eine Eigenschaft von ist – das Modell nach außen oder der Kunde nach innen – bestimmt, was die Architektur am Ende ist, was sie übersteht und wem sie zwei Jahre nach dem Ende des Engagements gehört.

Eine kurze Anmerkung zum regulatorischen Hintergrund, da er sich weiterentwickelt. Die EU Digital Omnibus-Einigung vom 7. Mai 2026 hat die Hochrisiko-Anhang-III-Verpflichtungen vom 2. August 2026 auf den 2. Dezember 2027 verschoben, und die Anhang-I-Verpflichtungen auf den 2. August 2028. [⁶] Die GPAI-Durchsetzungsbefugnisse gemäß Kapitel V bleiben im ursprünglichen Zeitplan vom 2. August 2026. Die strategische Implikation ist unverändert: Die Architektur- und Delivery-Entscheidungen von Q3 und Q4 2026 sind diejenigen, die bestimmen, ob der europäische Enterprise-KI-Stack die Beschaffungszyklen 2027 intakt übersteht.

Die Richtung ist entscheidend. Das ist die Arbeit vor uns, und es ist die Arbeit, die wir tun.

¹ Serienartikel auf neuland.ai/insights. Frühere Beiträge haben behandelt: Kontrollpanels und Ausführungsoberflächen; Modell-Drift, Multi-LLM-Strategie und Observability; Modell-Topologie und Hyperscaler-Unabhängigkeit; Compliance als Systemeigenschaft; Agentensicherheit und die letale Trifecta; MCP-Protokoll-Governance; die Fast-Follower-Workhorse-These mit souveränem Deployment; die neuen Enterprise-Datensilos, die durch SAP / Microsoft / ServiceNow / Salesforce KI-Gateways entstehen; Flexibilität als Architektur angesichts des Fable-5-Recalls und des europäischen Workhorse-Ökosystems; das Ontologie-Rennen, das von SAP / Microsoft / Google / Palantir gestartet wurde; und das Argument gegen das visuelle Workflow-Builder-Paradigma.

² PYMNTS Intelligence, „The Enterprise AI Benchmark Report," Juni 2026. Befragung von Führungskräften in Unternehmen mit mindestens 1 Milliarde US-Dollar Jahresumsatz. Einundsiebzig Prozent identifizierten die organisatorische Bereitschaft als primäre Barriere für KI-Leistung; elf Prozent nannten die Technologie selbst.

³ Uber hat sein KI-Budget für 2026 innerhalb der ersten vier Monate aufgebraucht; Starbucks hat sein KI-Inventarsystem nach neun Monaten eingestellt. Beide Fälle wurden in Q2 2026 im Enterprise-KI-ROI-Kommentar breit berichtet; siehe MarketScale, „Enterprise AI's center of gravity shifts from models to orchestration, governance, and ROI clarity," 5. Juli 2026. Monatliche Stellenausschreibungen für Forward-Deployed Engineers stiegen zwischen Januar und September 2025 um mehr als 800 Prozent, laut PYMNTS Intelligence-Tracking, zitiert in „AI Giants Pour Billions Into Enterprise Deployment," Juli 2026.

⁴ GLM-5.2, veröffentlicht von Z.ai am 13.–16. Juni 2026 unter der MIT-Lizenz. 753-Milliarden-Parameter Mixture-of-Experts-Architektur mit ungefähr 40 Milliarden aktiven Parametern pro Token, 1-Million-Token-Kontextfenster. Benchmarks: 62,1 SWE-bench Pro, 81,0 Terminal-Bench 2.1, innerhalb von ungefähr 1 Prozentpunkt von Claude Opus 4.8 auf FrontierSWE, zu ungefähr 1/6 der Token-Kosten proprietärer Frontier-APIs. Siehe den Ontologie-Beitrag und den Workhorse-Beitrag früher in dieser Reihe für das zugrundeliegende Kommoditisierungsargument.

⁵ neuland.ai HUB-Plattformarchitektur, veröffentlicht als Teil der öffentlichen HUB-Materialien. Kernelemente: Orchestrator-Routing pro Ontologie und SLM pro Domäne / Anwendung (deterministisch oder agentisch); agentisches Retrieval und Reasoning (agentisches RAG, rekursive Sprachmodelle, agentische Threads, Deep Agents, Multi-Hop-Reasoning, KAG, Query Planning, semantisches Re-Ranking); Ontologie-Schicht (Unternehmensontologie und Connector-Ontologien, automatisch aus Kundendaten generiert, kontinuierlich aktualisiert, materialisiert als Wissensgraph, Skills, Regeln, Vektorindex); Governance und Compliance (Rollen und Rechte, Guardrails, Audit-Trail, EU AI Act / DORA / BaFin / DSGVO / BRAO, Erklärbarkeit via AtMan und Aleph Alpha); Observability und Logging über alle Connectors und agentischen Prozesse; Petabyte-skalige Ingestion-Pipelines auf Kubernetes-GPU-Clustern; souveränes Deployment auf STACKIT mit On-Premises-, Private-Cloud- und Hybrid-Optionen; modell-agnostische Modellschicht (proprietäre Frontier-Modelle via Cloud-API, wo der Workload es erlaubt; selbst gehostete SLMs – Qwen, gpt-oss, DeepSeek, Mistral, Llama, Cohere, Pharia-1 mit AtMan von Aleph Alpha – für souveräne Workloads). neuland.ai AG trägt die Verantwortung für die Inhaltsqualität und saubere Ergebnislieferung in allen Kundenengagements.

⁶ Vorläufige politische Einigung des Rates der EU und des Europäischen Parlaments zum Digital Omnibus zu KI, 7. Mai 2026. Anhang-III-Hochrisiko-Verpflichtungen verschoben vom 2. August 2026 auf den 2. Dezember 2027 (16-monatige Verzögerung); Anhang-I-Verpflichtungen verschoben auf den 2. August 2028 (12-monatige Verzögerung); Artikel 50(2) Wasserzeichenpflicht verschoben auf den 2. Dezember 2026. GPAI-Durchsetzungsbefugnisse gemäß Kapitel V bleiben im ursprünglichen Zeitplan vom 2. August 2026.