Apple Core AI: de edge-laag in je federatieve AI-architectuur — wat CISO's en architecten moeten weten

Apple heeft met Core AI en de open-source coreai-models repository een nieuwe AI-laag gelanceerd die fundamenteel verschilt van Core ML. Het is geen rebranding, het is een nieuwe, gespecialiseerde on-device AI-runtime voor Apple Silicon, met een eigen modelartefactformaat (.aimodel), een Swift-native API, ahead-of-time compilatie, en een volledige authoring- en optimalisatiepipeline vanuit PyTorch.

Voor de Nederlandse publieke sector is dit relevant omdat Core AI een technische infrastructuur biedt voor privacy-preserving, cloud-onafhankelijke AI op Apple hardware. Maar "on-device" is geen governance-garantie. Dit artikel plaatst Core AI in een federatieve enterprise-architectuur, analyseert de security-implicaties, en biedt een concreet experimentplan voor organisaties die willen piloten.

---

Core AI is geen Core ML 2.0, dit is de architectuur

Apple's eigen documentatie is helder: Core ML blijft bestaan voor niet-neurale modellen (beslisbomen, tabulaire feature engineering). Core AI is een parallelle, gespecialiseerde stack voor neurale netwerk-inference op Apple Silicon.

De technische architectuur bestaat uit vier lagen:

Runtimeframework. De Swift API exposeert AIModel, InferenceFunction, NDArray (multidimensionale arrays) en ComputeStream. Het framework verdeelt inference automatisch over CPU, GPU én Neural Engine, met fijnmazige controle over specialization (modeloptimalisatie voor een specifiek device), caching, en geheugengebruik. Apple benadrukt zero-copy data paths, stateful execution (bijv. key-value cache als input voor transformer-inference), en AOT-compilatie via coreai-build.

Modelartefactlaag. Het .aimodel-formaat is het universele exportformaat. Een export produceert een standalone .aimodel of een bundel met resources (tokenizer, configuratie, metadata). De Swift package (coreai-models) levert runtime utilities voor integratie in apps, met libraries voor CoreAILM, CoreAIDiffusion, CoreAISegmentation en CoreAIObjectDetection.

Authoring- en optimalisatiepipeline. Drie complementaire Python-componenten:

• coreai-torch, converteert torch.export.ExportedProgram naar Core AI IR, met ondersteuning voor composite ops, custom lowerings en inline Metal GPU-kernels
• coreai-opt, compressietechnieken: quantisatie, palettisatie, pruning; van data-free tot fine-tuning-gebaseerd
• coreai-core, Python-modules voor het authorien en laden van .aimodel-bestanden

Developer toolchain. coreai-build (CLI voor AOT-compilatie), Core AI Debugger (tensor-visualisatie met traceback naar Python source), en Instruments-integratie voor inference profiling. Xcode 27 integreert dit in de IDE.

Modelcatalogus. De repo biedt export recipes voor 20+ architecturen:

Categorie	Modellen
Large Language Models	Gemma3, GPT-OSS, Mistral, Mixtral, Qwen2.5, Qwen3 (0.6B-8B), Qwen3 MoE
Diffusion / Image Generation	Stable Diffusion 1.5, 2.1, 3.5 Medium, FLUX.2
Vision	CLIP, Depth Anything v3, EDSR, EfficientSAM, PVT v2, SAM 3, YOLOS
Audio	CLAP, Wav2Vec2, Whisper (large-v3, large-v3-turbo)
Text / NLP	RoBERTa, T5

Elk model heeft een export recipe met uv run, de pipeline is uniform en reproduceerbaar.

---

De modelpipeline in detail: wat gebeurt er in een export?

Voor een LLM zoals Qwen3 0.6B, het kleinste model dat Apple voor iOS ondersteunt, ziet de pipeline er zo uit:

uv run coreai.llm.export Qwen/Qwen3-0.6B \
  --platform iOS \
  --compression none \
  --max-context-length 2048

Dit produceert een .aimodel bestand plus een resource bundle. De OS-specifieke parameters zijn significant: macOS gebruikt een dynamische KV-cache die zich aanpast aan de context lengte, terwijl iOS statische shapes vereist met een expliciete --max-context-length bij export.

Apple adviseert voor iOS zelfs model-specifieke mixed 4-bit/8-bit compressie-recepten in YAML-formaat, wat betekent dat je per model en per target platform een afweging moet maken tussen modelgrootte, kwaliteit en context lengte. De registry laat zien dat Apple voor elke model-preset concrete defaults vastlegt voor compressie, precision en context length per platform.

Voor Qwen3 geldt: 0.6B en 4B ondersteund op macOS en iOS, 8B alleen macOS. Dit patroon (grote modellen alleen desktop, kleinere op mobile) is consistent met de hardwarebeperkingen van de Neural Engine en unified memory.

---

Positionering: waar Core AI past in een federatieve stack

De belangrijkste architectuurvraag is niet "is Core AI goed?" maar "waar hoort Core AI in een enterprise AI-stack?" Het antwoord is: als Apple edge-runtime, niet als centrale modelgateway.

Laag	Beste rol	Waarom
Core AI	Apple edge-runtime	Native on-device inference, Swift-integratie, zero server dependency, geen tokenkosten, AOT-compilatie. Privacywinst door data die device niet verlaat.
MLX	Apple research & prototyping	Array framework voor ML op Apple Silicon, CPU/GPU/unified memory, research-vriendelijke API. Sterk voor experimentatie, niet voor distributie in apps.
Ollama	Lokale modelserver (dev/workstation)	OpenAI-compatibele API, geschikt als eenvoudige lokale modelservice voor ontwikkelaars.
vLLM / SGLang	Centrale inference serving	High-throughput LLM-serving, GPU-batching, geschikt voor server-side productie-inference.
LiteLLM	Centrale model- en provider-gateway	Uniforme proxy-interface voor meerdere providers, met routing, spend tracking, guardrails en logging.

Core AI is embedded runtime, dicht bij de gebruiker, op het device, zonder netwerkafhankelijkheid. De andere vier zijn research-, serving- of gatewaylagen. Dit is geen concurrentie maar complementariteit.

Een werkende federatieve architectuur ziet er zo uit:

1. Edge-laag (Core AI): privacygevoelige, latency-kritische, of kleine inference-taken, documentanalyse op device, lokale transcriptie, on-device image segmentatie, kleine LLM-query's
2. Lokale serving-laag (Ollama, MLX): grotere modellen op een developer workstation of lokale server, prototyping, modelvalidatie, grotere context-query's
3. Centrale serving-laag (vLLM/SGLang): high-throughput productie-inference, batchverwerking, zware LLM-workloads, multi-tenant
4. Gateway-laag (LiteLLM): routing, policy enforcement, logging, bepaalt welke verzoeken naar welke laag gaan, welke providers mogen worden gebruikt, en wat wordt gelogd

De routinglogica is eenvoudig: eerst edge, dan lokaal, dan centraal, dan cloud. Een agent of app bepaalt of een taak privacygevoelig, klein of latency-kritisch genoeg is voor Core AI. Alleen als de taak te groot, te complex of te extern georiënteerd is, wordt doorgerouteerd naar een centrale service of cloudprovider.

---

Security- en governance-implicaties

Core AI verlaagt één klasse risico's, data-exfiltratie via cloud-inference. Wanneer een model volledig on-device draait, verlaten persoonsgegevens het device niet. Dat is een direct voordeel voor AVG-compliance en DPIA's.

Maar "on-device" is geen compliancetheologie. Artikel 25 AVG (privacy by design) blijft onverkort gelden. En er ontstaan nieuwe governance-vraagstukken:

Supply-chain risico. De repo exporteert modellen van HuggingFace. Sommige modellen (SAM3) vereisen gated access met een HF-token. De Python-configuratie toont een keten van pinned dependencies: coreai-core==1.0.0b1, coreai-torch==0.4.0, coreai-opt==0.2.0, torch==2.9.0, transformers>=4.57, diffusers>=0.37, huggingface-hub>=0.34. Model provenance, tokenizer-integriteit, dependency pinning, export reproduceerbaarheid, artifact hashing en license review zijn geen optionele kwaliteitskenmerken maar operationele vereisten. Dit sluit aan bij OWASP LLM05 (supply chain vulnerabilities).

Modelartefact-beheer. .aimodel-bestanden zijn binaire artifacts die een lifecycle nodig hebben: build → sign → hash → versieer → distribueer → monitor → retire. Ze moeten behandeld worden als release artifacts, niet als data files.

Inference governance. De centrale governance-vragen: Welke modellen mogen draaien op welke devices? Welke input data mag naar welk model? Hoe audit je lokale inferentie? Hoe voorkom je dat een lokaal model via crash logging of telemetry alsnog persoonsgegevens exfiltreert?

Minimale control set voor Core AI:

Control	Implementatie
AI-SBOM	Per .aimodel of modelbundle: bronmodel + commit/hash, export recipe, tokenizer, compressieconfig, Core AI versie, Xcode versie, target platform
Artifact signing	.aimodel-bestanden signeren, hashen, versiëren, gecontroleerd distribueren via MDM
Routing policies	Welke datacategorieën mogen uitsluitend lokaal? Welke mogen naar centrale lokale service? Welke pas na redactie/classificatie naar externe providers?
Output validatie	Schema-validatie of typed generation waar mogelijk, zeker voor lokale agent-preprocessing
Privacy-by-design telemetry	Crash logging en model downloads zo ontwerpen dat observability geen AVG-schending introduceert

Deze control set is een synthese van OWASP LLM Top 10, NIST AI RMF 1.0, NIST CSF 2.0, ISO 27001:2022 en de EU AI Act, aangepast aan de specifieke eigenschappen van on-device AI.

---

Experimentplan: hoe te piloten

De juiste pilot is klein, reproduceerbaar en meetbaar. Gebaseerd op Apple's eigen export recipes en tools:

Experiment	Route	Wat te meten	Waarom eerst
Qwen3 0.6B op macOS	uv run coreai.llm.export Qwen/Qwen3-0.6B → swift run -c release llm-runner → swift run -c release llm-benchmark	Exportduur, modelgrootte, cold start, first-run specialization, cached latency, output kwaliteit, geheugenverbruik	Apple's eigen referentiepad voor compacte on-device LLM-inference met duidelijke macOS/iOS presets
Whisper audio transcriptie	uv run export.py in models/whisper/	Artifactgrootte, transcriptiekwaliteit, latency per audiominuut, float16 vs float32	Geeft snel zicht op privacywinst door lokale transcriptie zonder complexe app-UX
EfficientSAM vision	Start met uv run export.py in models/efficient-sam/	Modelgrootte, segmentatiekwaliteit, cold start, lokale UX-latency	Laag risico, licht model (~10M params), direct bruikbaar voor private image workflows

Vier besliscriteria voor go/no-go:

1. Performance, is first-run specialization beheersbaar met caching of AOT-compilatie?
2. Quality, levert het model genoeg businesswaarde t.o.v. externe of centrale runtime?
3. Operational fit, past distributie via app assets of on-demand download in de lifecycle?
4. Governance fit, kun je provenance, logging, privacyclassificatie en artifact-beheer voldoende hard maken?

Apple's eigen WWDC26-sessies leggen specifiek nadruk op precies deze vier punten: diagnosing specialization latency, on-demand deployment buiten de app bundle, en AOT-compilatie met xcrun coreai-build compile.

---

Strategisch advies

Core AI is strategisch relevant, maar operationeel nog vroeg. De documentatie is beta, de OS-versies zijn nieuw (iOS 27+, macOS 27+), de repo heeft een gesloten PR-beleid, en de enterprise-operationele patronen zijn nog niet bewezen.

Go: Opname van Core AI in de capability map als local-private edge-runtime op Apple devices. Een gerichte pilot op recente Apple hardware voor privacygevoelige, lokale en app-embedded use cases.

No-go: Opname als centrale modelgateway of als vervanging van de bredere inference stack. Core AI is geen vervanger voor vLLM, LiteLLM of Ollama, het is een aanvullende laag aan de rand van het systeem.

Eerste stappen:

1. Richt één coreai-lab in op een recente Mac met Xcode 27 en Python 3.11
2. Beperk de eerste fase tot read-only discovery en exporttests
3. Integreer pas daarna de Codex of Claude skills in de agent-kennisbasis
4. Formaliseer pas na benchmarkresultaten een routingpolicy waarin Core AI uitsluitend lokale, privacygevoelige en latency-kritische taken krijgt

Alles daarbuiten blijft in de bestaande federatieve stack.

---

Conclusie

Apple Core AI is een serieuze toevoeging aan het on-device AI-landschap. Het biedt een technisch volwassen, hardware-geoptimaliseerde runtime voor een breed scala aan modelarchitecturen, van LLM tot diffusion tot vision, met een reproduceerbare exportpipeline en native Swift-integratie.

Voor de Nederlandse publieke sector is de relevatie eenvoudig: Core AI maakt privacy-preserving, cloud-onafhankelijke AI-inference mogelijk op Apple hardware. Geen data die het device verlaat, geen cloud provider, geen verwerkersovereenkomst voor inferentie. Maar "on-device" is geen governance-garantie, het vereist een eigen control set voor supply chain, artifact management, routing policies en privacy-by-design telemetry.

De juiste positionering is als edge-laag in een federatieve architectuur, complementair aan MLX, Ollama, vLLM en LiteLLM, niet als vervanger. Core AI is de beste keuze voor wat klein, lokaal, privacygevoelig of latency-kritisch is. Alleen wat daar niet in past, routeer je door naar de volgende laag.

---

Gebaseerd op: Apple Inc. (2026). coreai-models, BSD 3-Clause. Core AI Documentation. iOS 27.0+/macOS 27.0+ Beta. WWDC26 sessies. Geanalyseerd in combinatie met MLX, Ollama, vLLM, SGLang en LiteLLM documentatie.