Künstliche Intelligenz
Oracle: Souveränitätsversprechen zwischen Anspruch und Wirklichkeit
Auf der Oracle AI World in Frankfurt präsentierten führende Oracle-Manager ihre Pläne für eine verteilte, souveräne und KI-fähige Cloud-Infrastruktur. Im Mittelpunkt stand die Frage, wie Unternehmen angesichts wachsender Datenschutzanforderungen und einer zunehmend fragmentierten Cloud-Landschaft handlungsfähig bleiben können. Andrew Bond, CTO von Oracle EMEA, setzte den Rahmen: Oracle sei nicht einfach ein weiterer Hyperscaler, sondern unterscheide sich architektonisch deutlich von der Konkurrenz. Ob diese Behauptung trägt, muss sich in der Praxis zeigen – die Argumente waren aber durchaus substanziell.
Weiterlesen nach der Anzeige
Oracles EU Sovereign Cloud läuft nach eigenen Angaben seit knapp drei Jahren in Frankfurt und Madrid. Sie wird ausschließlich von EU-Personal betrieben und ist vom öffentlichen Oracle-Cloud-Netz physisch getrennt. Technisch basiert sie auf denselben OCI-Bausteinen wie die öffentliche Cloud, läuft aber in einem eigenen, isolierten Realm. Damit reagiert Oracle auf eine zentrale Sorge europäischer Kunden: Daten sollen die EU nicht verlassen, und die Betriebsverantwortung liegt nachweislich in der EU.
Antonio Freitas, bei Oracle EMEA für die Sovereignty-Strategie verantwortlich, erläuterte in einer Roundtable-Session die Entwicklung des Angebots: Sein Team habe intensiv mit EU-Institutionen wie der Europäischen Kommission, ENISA und nationalen Regulierungsbehörden zusammengearbeitet. Das Ziel: die Anforderungen an souveräne Cloud-Infrastruktur nicht nur zu verstehen, sondern sie frühzeitig in die Produktentwicklung einfließen zu lassen. Inwieweit Oracle damit näher an einer EUCS-Zertifizierung (EU Cloud Services Scheme) ist als etwa AWS oder Azure, blieb auf der Veranstaltung allerdings offen.
Dass das Konzept in der Praxis trägt, sollte ein Kundenbeispiel belegen: Stefan Moch, VP von Arvato Systems, berichtete über den Betrieb von Arzneimittel-Verifikationssystemen gemäß der EU-Richtlinie FMD (Falsified Medicines Directive). Das System verarbeite allein in Deutschland täglich fünf bis sechs Millionen Apothekentransaktionen und europaweit rund 35 bis 40 Millionen Packungsverifizierungen. Hochverfügbarkeit und niedrige Latenzzeiten seien ausschlaggebend gewesen. Unabhängig überprüfbar waren diese Leistungswerte auf der Veranstaltung nicht.
Einheitliches Pricing: Versprechen mit Fragezeichen
Ein Argument, das Bond in der Keynote mehrfach unterstrich: Oracle berechnet für Cloud-Dienste in Europa denselben Preis wie in den USA. Da der Rechenzentrumsbetrieb in Deutschland deutlich teurer sei, bedeute das für europäische Kunden einen erheblichen Kostenvorteil. Oracle beziffert die Einsparungen gegenüber Mitbewerbern auf 30 bis 50 Prozent – wohlgemerkt nach Eigenangaben, nicht unabhängig geprüft.
Tatsächlich zeigen öffentlich einsehbare Preislisten, dass AWS und Azure für die Region Frankfurt häufig höhere Listenpreise aufrufen als für US-Regionen. Ob die Oracle-Rechnung unter Berücksichtigung von Enterprise-Rabatten, Reserved Instances und Committed-Use-Modellen der Mitbewerber in dieser Höhe standhält, bleibt offen. Kunden sollten hier eigene TCO-Vergleiche anstellen.
Dedicated Region und Alloy: Die Cloud im eigenen Rechenzentrum
Weiterlesen nach der Anzeige
Neben der öffentlichen Cloud und der EU Sovereign Cloud stellte Oracle seine Dedicated Region und das Alloy-Modell vor. Die Dedicated Region ermöglicht es Unternehmen, die vollständige OCI-Infrastruktur inklusive SaaS, PaaS und IaaS im eigenen Rechenzentrum zu betreiben, ab drei Racks. Vodafone hat damit nach Oracle-Angaben 40 Rechenzentrumsstandorte in sechs Dedicated Regions konsolidiert, zwei davon in Deutschland.
Das Alloy-Modell setzt anders an: Partner können eigene Cloud-Angebote auf OCI-Basis aufbauen. Als Referenzen nannte Oracle die japanische Sovereign Cloud von Fujitsu und die Thai Cloud von AIS. Konzeptionell erinnert Alloy an Angebote der Konkurrenz wie AWS Outposts, Azure Stack oder Googles Distributed Cloud. Durch die vollständige SaaS-Verfügbarkeit hebt sich Oracle aber ab. Oracle betont, dass es sich bei allen Varianten technisch um exakt dieselbe Plattform handelt.
Multi-Cloud-Portabilität: Brücken zu AWS, Azure und Google
Ein weiterer Schwerpunkt war Oracles Multi-Cloud-Strategie. Das Unternehmen hat Teile seiner OCI-Infrastruktur direkt in Rechenzentren von Microsoft Azure, Google Cloud und AWS integriert. Oracle-Datenbankservices wie die Autonomous Database lassen sich dort nativ nutzen. Wer etwa Amazon Bedrock mit einer Oracle-Datenbank kombinieren will, muss keine Daten in eine andere Umgebung migrieren.
Passend dazu kündigte Oracle die Multi-Cloud Universal Credits an: ein einheitliches Verbrauchsmodell, das Oracle-Datenbankservices flexibel zwischen OCI, AWS, Azure und Google Cloud verschiebbar machen soll – ohne jeweils neue Vertragsverhandlungen. Die Idee klingt in Zeiten schnell wechselnder KI-Strategie, die zuletzt für ein starkes Umsatzwachstum im Cloud-Geschäft sorgten plausibel, wirft aber auch Fragen auf: Wie portabel sind Workloads in der Praxis wirklich, wenn sie auf Oracle-proprietäre Features wie die Autonomous Database angewiesen sind? Echte Multi-Cloud-Portabilität bleibt auch bei Oracle an das eigene Ökosystem gebunden.
Architekturentscheidungen: Bare Metal und RoCE statt Virtualisierung und InfiniBand
Oracle begründet seine Leistungs- und Kostenargumentation mit grundlegenden Architekturentscheidungen. Anders als AWS und Azure setzt Oracle konsequent auf Bare-Metal-Instanzen: Workloads laufen direkt auf dedizierter Hardware ohne Hypervisor-Overhead – das soll besonders datenbankintensiven Anwendungen zugutekommen. Für die Netzwerkanbindung setzt Oracle sowohl auf RoCE (RDMA over Converged Ethernet) statt auf InfiniBand und kombiniert das mit der hauseigenen Acceleron-Architektur, um Verkabelungsaufwand bei großen GPU-Clustern zu reduzieren. Beide Entscheidungen haben allerdings auch Kehrseiten: Ohne Hypervisor entfällt die flexible Ressourcenverteilung zwischen Workloads, und ob RoCE bei sehr großen Cluster-Topologien mit dem Congestion-Management von InfiniBand mithalten kann, ist in der Branche umstritten.
KI-Strategie: Datenplattform statt Modellrennen
Den Abschluss der Veranstaltung bildete Oracles KI-Strategie. Mit der AI Data Platform will Oracle private Unternehmensdaten sicher mit generativen KI-Modellen verbinden, statt eigene Foundation Models zu entwickeln. Kernelement ist die Autonomous Database, die neben relationalen Daten auch Vektoren, JSON, Graph- und Spatial-Daten unterstützt und sich über offene Formate wie Apache Iceberg mit externen Datenspeichern verbinden lässt.
Der Ansatz, sich als Datenplattform für KI zu positionieren, statt im Wettlauf um eigene Modelle mitzumischen, ist nachvollziehbar: Die meisten Unternehmen kämpfen weniger mit der Verfügbarkeit von Modellen als mit der Integration und Governance ihrer eigenen Daten. Konkrete Referenzkunden aus dem deutschsprachigen Raum blieb Oracle allerdings schuldig.
Fazit: Starke Argumente, offene Fragen
Oracle präsentierte sich auf der AI World als relevante Alternative für Unternehmen mit hohen Anforderungen an Datensouveränität und Datenbankperformance. Die Sovereign-Cloud-Architektur, das einheitliche Pricing und die Multi-Cloud-Integration sind nachvollziehbare Unterscheidungsmerkmale gegenüber den drei großen Hyperscalern. Naturgemäß blieben die zentralen Versprechen auf einer solchen Marketingveranstaltung ungeprüft. Kunden sollten Kostenvorteile anhand eigener Workloads validieren und hinterfragen, wie portabel ihre Anwendungen tatsächlich sind, wenn sie tief in Oracle-proprietäre Features investiert haben.
Lesen Sie auch
(fo)
Künstliche Intelligenz
So funktioniert die Umstellung eines automatisierten CI-Prozesses mit KI
Der Vorteil von Linux-Distributionen gegenüber einem selbst konfigurierten Linux-System ist der modulare und leicht zu wartende Aufbau. Ähnlich einem Baukasten lassen sich verschiedene Werkzeuge nachinstallieren und miteinander kombinieren. Einen großen Anteil an einer unkomplizierten Systemwartung hat dabei das Paketmanagement. Deshalb ist es erstrebenswert, eigene Software in Form von Softwarepaketen auszuliefern, die sich in die Paket-Infrastruktur einer Distribution einfügen und mit den Werkzeugen dieser Distribution verwalten lassen.
Dieser Beitrag stellt einen Delivery-Workflow für Pakete einer Linux-Distribution vor, der mithilfe von Shell-Skripten implementiert wurde. Dieser Workflow lässt sich in eine Jenkins-Pipeline einbetten, ist für den Regressionstest und zur Paketerzeugung gedacht und lässt sich dann nach einem Commit automatisch anstoßen und ausführen. Die Skripte nutzten eine ältere Linux-Distribution. Mithilfe agentischer KI wurde auf eine neuere Distribution umgestellt und es wurden Fehler bereinigt. Zum Einsatz kamen Open-Source-Werkzeuge der Distribution.
Problemstellung
Um Pakete in einer zufriedenstellenden Qualität ausliefern zu können, ist ein Workflow notwendig, der neben dem Paketbau den Modul-, den Integrations- und – soweit möglich – auch den Systemtest enthält. Die Tests sind in einzelne Stages aufgeteilt, jeder Stage ist dabei ein eigener Bereich gewidmet. Darunter soll überprüft werden, ob sich benötigte Pakete in der Testumgebung installieren lassen, ob die Gerätetreiber gebaut werden können – hier ergeben sich Anknüpfungspunkte für automatisierbare Tests mit angeschlossener Hardwareperipherie –, und schließlich, ob der Quellcode übersetzt werden kann und den Regressionstest im ebenfalls generierten Testprozessor besteht.

Christian Kuhn hat an der TU Ilmenau Automatisierungstechnik / Systemanalyse studiert und arbeitet freiberuflich als Entwickler und Tester. Seine Spezialisierungsrichtung ist die modellbasierte Entwicklung von Komponenten für Steuerungssysteme u.a. in der Automobilindustrie.
Sind alle Tests bestanden, werden anschließend die beim Build-Vorgang erzeugten Binärdateien gepackt und Installationspakete ausgeliefert. Im Anschluss wird noch überprüft, ob sich die Pakete in der temporär erzeugten Testumgebung selbst wieder installieren lassen und die Dienste gestartet werden können, weitere Tests können sich anschließen.
Das war die Leseprobe unseres heise-Plus-Artikels „So funktioniert die Umstellung eines automatisierten CI-Prozesses mit KI“.
Mit einem heise-Plus-Abo können Sie den ganzen Artikel lesen.
Künstliche Intelligenz
Medizin: Führende LLMs schlagen spezialisierte kleine Sprachmodelle klar
Eine aktuelle Studie in Nature Medicine verglich spezialisierte klinische KI-Systeme (OpenEvidence und UpToDate Expert AI) mit großen Sprachmodellen (LLMs) führender KI-Unternehmen (OpenAI, Google und Anthropic). In den verschiedenen Tests innerhalb der Studie lagen diese allgemeinen LLMs vor den spezialisierten medizinischen KI-Systemen.
Weiterlesen nach der Anzeige
Spezialisierte KI-Anwendungen für medizinische Fragen und Recherchen werden von vielen Ärztinnen und Ärzten verwendet. Anbieter versprechen dabei, dass ihre Systeme durch domänenspezifische Trainingsdaten oder Retrieval-Augmented Generation (RAG) gezielt optimiert wurden und ideal für die Anwendung in der Medizin sind.
Ein Forschungsteam aus New York (NYU Langone Health) hat nun in einer im Fachjournal Nature Medicine veröffentlichten Studie zwei spezialisierte medizinische KI-Systeme mit Allzweck-LLMs führender KI-Unternehmen verglichen. Das Ergebnis fällt deutlich aus: In allen drei untersuchten Testbereichen waren die LLMs von OpenAI, Google und Anthropic besser als spezialisierte klinische KI.
Vergleich über drei unterschiedliche medizinische Tests
Die untersuchten klinischen KI-Tools OpenEvidence und UpToDate Expert AI richten sich beide an medizinische Fachkräfte und sollen Fachfragen beantworten. Verglichen wurden diese mit den führenden LLMs GPT-5.2 (OpenAI), Gemini 3.1 Pro Preview (Google) und Claude Opus 4.6 (Anthropic). In einem Teil der Untersuchung wurde außerdem Google Search AI Overview als realitätsnaher Vergleich einbezogen, zumal diese Funktion im Alltag von Ärztinnen und Ärzten jederzeit zur Verfügung steht.
Das Studiendesign bestand aus drei Teilen. Im ersten Teil beantworteten die Systeme 500 medizinische Fragen im Stil der US-amerikanischen medizinischen Zulassungsprüfung (MedQA Benchmark). Im zweiten Teil folgten 500 Aufgaben aus HealthBench, einem Benchmark zur Bewertung medizinischer Antworten entlang ärztlicher Kriterien. Im dritten, besonders praxisnahen Teil entwickelten die Forscher einen „Real-Clinical-Queries-Benchmark (RCQ)“. Hierfür wurden 100 anonymisierte Anfragen verwendet, die Ärztinnen und Ärzte im Alltag tatsächlich an eine GPT-Instanz der NYU Langone Health gestellt hatten. Die Antworten auf diese realen klinischen Fragen wurden von zwölf US-amerikanischen Mediziner:innen verblindet und randomisiert bewertet. Bewertet wurden klinische Korrektheit, Vollständigkeit, Sicherheit und Verständlichkeit auf einer Skala von 1 bis 4. Insgesamt entstanden dadurch 1800 Modell-Frage-Bewertungen.
Weiterlesen nach der Anzeige
Allgemeine LLMs mit besseren Ergebnissen bei medizinischem Wissen
Im klassischen medizinischen Wissensbenchmark MedQA lag Gemini mit einer Genauigkeit von 97,4 Prozent an der Spitze, während GPT-5.2 94,2 Prozent und Claude 90,2 Prozent erreichten. Die beiden spezialisierten klinischen Systeme erreichten hierbei nur 89,6 Prozent (OpenEvidence), bzw. 88,4 Prozent (UpToDate AI).
Auch im HealthBench-Test waren die allgemeinen LLMs besser. GPT-5.2 erzielte 88,0 von 100 möglichen Punkten, während Gemini 79,3 Punkte und Claude 77,0 Punkte erzielten. OpenEvidence und UpToDate Expert AI lagen mit 62,6 und 61,3 Punkten deutlich dahinter.
Die realen, anonymisierten Anfragen von Ärztinnen und Ärzten im RCQ-Benchmark konnten die allgemeinen LLMs ebenfalls besser beantworten. Sie erreichten auf der vierstufigen Bewertungsskala im Mittel 3,62 (Gemini), 3,54 (GPT-5.2) und 3,52 (Claude) Punkte, während OpenEvidence 3,24 Punkte und UpToDate Expert AI 3,17 Punkte erzielte. Google AI Overview, also die allgemeine Suchfunktion in Google mit KI-Antwort, lag mit 3,27 Punkten in etwa auf dem Niveau der medizinischen Systeme.
Die Ergebnisse widersprechen der naheliegenden Erwartung, dass medizinisch optimierte KI bei medizinischen Fragen besser sind als die allgemeineren Systeme führender Tech-Unternehmen. Die Autor:innen vermuten, dass die umfangreicheren Trainingsdaten und schnellere Entwicklungszyklen der führenden Allzweck-LLMs in vielen Aufgaben stärker ins Gewicht fallen könnten als eine nachträgliche Spezialisierung auf medizinischen Daten.
Probleme bei Vollständigkeit, Struktur und Auslassungen
In der Beurteilung der Antworten durch die Mediziner:innen fanden sich keine statistisch signifikanten Unterschiede zwischen den Systemen bezüglich Sicherheit. Das bedeutet jedoch nicht, dass die Antworten der spezialisierten Systeme gleich gut waren. In Freitextanmerkungen der ärztlichen Beurteiler wurden bei OpenEvidence und Google AI Overview besonders häufig unvollständige klinische Inhalte und sicherheitsrelevante Auslassungen vermerkt. OpenEvidence fiel zudem durch vergleichsweise unübersichtliche oder schwer nachvollziehbare Antworten auf.
UpToDate Expert AI verweigerte außerdem deutlich häufiger eine Antwort als die anderen Systeme. Im RCQ-Test wurden 19 Prozent der Anfragen von UpToDate Expert AI verweigert. Bei den allgemeinen LLMs lag dieser Anteil dagegen nur zwischen einem und drei Prozent.
Warum Spezialisierung nicht automatisch hilft
Die Wissenschaftler:innen betonen, dass sie wegen der proprietären Architektur der Systeme nicht sicher erklären können, warum die klinischen Systeme schlechter abschnitten. Eine mögliche Erklärung ist, dass die wesentlich größeren, allgemeinen LLMs gerade bei Aufgaben, die medizinisches Wissen, Argumentation und verständliche Kommunikation kombinieren, von ihrer Größe und ihrem breiten Wissen profitieren. Die Studie sollte nicht als endgültiges Ranking aller Ansätze verstanden werden. Die Autor:innen weisen ausdrücklich darauf hin, dass stark spezialisierte Teilgebiete, komplexe lokale Workflows oder institutionseigene Modelle andere Ergebnisse liefern könnten.
Bedeutung für Kliniken und Regulierung
Die Ergebnisse sind für Krankenhäuser und Praxen relevant, weil spezialisierte klinische KI-Produkte oft mit institutioneller Glaubwürdigkeit auftreten. Die Studie zeigt jedoch auf, dass ein KI-System nicht automatisch besser ist, nur weil es gezielt für die Medizin entwickelt wurde. Zumindest in den untersuchten Aufgaben waren die allgemeinen Modelle von OpenAI, Google und Anthropic den klinischen KI-Systemen klar überlegen.
Für Beschaffung, Erstattung und Regulierung von Gesundheits-KI ergeben sich wichtige Konsequenzen. Entscheidend sollte sein, wie gut ein System in unabhängigen Tests und auf realistischen Aufgaben funktioniert und nicht, ob es als klinisches Spezialprodukt vermarktet wird. Die Autor:innen empfehlen daher strengere, unabhängige Evaluationen, bevor KI-Systeme breit in klinische Arbeitsabläufe integriert werden.
(mack)
Künstliche Intelligenz
Maker-Projekt: Bilder auf Platinen platzieren
In verschiedenen Projekten haben wir bereits beschrieben, wie man PCBs – Printed Circuit Boards, also geätzte Platinen – mit Onlineeditoren entwerfen und dann für kleines Geld herstellen lassen kann.
Fünf Platinen in Visitenkartengröße kosten inklusive Versand rund 5 Euro, bei größerer Stückzahl sogar unter 50 Cent pro Stück. Damit eignen sie sich auch hervorragend als Visitenkarten zum Verschenken – und genau die dienen in diesem Artikel als Beispielprojekt.
- Platinenebenen als Gestaltungsfläche nutzen
- Bilder in Farbkanäle zerlegen
- Zerlegte Bilder ins PCB-Layout importieren
Checkliste
Zeitaufwand: ca. 2 – 3 Stunden
Kosten: ab 5 Euro für 5 Platinen inkl. Versand
Material
- Platine (vom Fertiger, zum Beispiel JLCPCB)
- SMD-LEDs (Bauform 0805 mit automatischem Farbwechseleffekt)
Werkzeug
- Heizplatte für SMD-Löten
Software
Wer ein Bild möglichst originalgetreu auf einer Platine benötigt, kann sich vom Platinenfertiger einfach ein mehrfarbiges Bild per Tintenstrahldrucker aufbringen lassen. Das ist aber keine Herausforderung. Viel reizvoller ist es, seine künstlerische Gestaltungsfreiheit auf die sehr begrenzte „Palette“ der Platine einzuschränken. Wer auf eine Platine „malen“ möchte, hat sich nämlich ein äußerst herausforderndes Medium ausgesucht.
Das war die Leseprobe unseres heise-Plus-Artikels „Maker-Projekt: Bilder auf Platinen platzieren“.
Mit einem heise-Plus-Abo können Sie den ganzen Artikel lesen.
-
Künstliche Intelligenzvor 3 Monaten
JBL Bar 1300MK2 im Test: Soundbar mit Dolby Atmos, starkem Bass und Akku‑Rears
-
Künstliche Intelligenzvor 3 MonatenOscars 2026: Was die heise‑Leser anders entschieden hätten
-
Künstliche Intelligenzvor 3 MonatenEmpfehlungsalgorithmen bei TikTok erklärt: Die Maschine hinter dem Endlos‑Feed
-
Social Mediavor 3 MonatenVon Kennzeichnung bis Plattformpflichten: Was die EU-Regeln für Influencer Marketing bedeuten – Katy Link im AllSocial Interview
-
Künstliche Intelligenzvor 2 Monaten„Don’t Starve Elsewhere“: Survival‑Hit kehrt nach zehn Jahren zurück
-
Künstliche Intelligenzvor 2 MonateniX-Workshop Angriffsziel lokales AD − Schwachstellen finden und beheben
-
Künstliche Intelligenzvor 2 MonatenWeitere Entlassungswelle bei Disney: Bis zu 1000 Mitarbeiter betroffen
-
Künstliche Intelligenzvor 2 MonatenKine‑Exakta: Die erste Spiegelreflexkamera fürs Kleinbild
