Most AI platforms make the AI Act your problem.
The EU AI Act doesn't ask whether your AI is clever — it asks whether you can prove where the data lives, what the system did, who oversaw it, and which model produced the answer. With a public-cloud LLM service, those proofs sit on someone else's infrastructure. With Emblema, they're a byproduct of the architecture.
Every obligation below maps to a real article of Regulation (EU) 2024/1689 and to a real, shipping Emblema capability — not a roadmap promise.
The Act applies in phases — and the bulk lands soon.
The teams that win the regulated market are the ones architected for it now.
Prohibited practices
Unacceptable-risk uses — social scoring, manipulation, mass biometric identification — are banned.
General-purpose model rules
Obligations for providers of general-purpose AI models, including systemic-risk tiers, apply.
High-risk obligations
The bulk of high-risk system obligations — data governance, logging, oversight, documentation — take effect.
Where competitors hit a wall — and where the architecture answers.
Each obligation is a real article of the Act. Each answer is a shipping Emblema capability, ranked by how decisive it is for a regulated buyer.
Your data never leaves the building — and you can prove it
Data sovereignty and data governance you actually control.
The AI Act expects you to govern the data your AI processes. You can't govern data you've handed to a third party's cloud — and under GDPR you often can't legally send it there in the first place.
ChatGPT Enterprise / OpenAI API, Microsoft 365 Copilot / Azure OpenAI, Google Gemini / Vertex AI, Anthropic Claude API, and AWS Bedrock are all delivered as managed cloud services: your prompts, documents, and embeddings are processed on the provider's infrastructure. Even "enterprise" and "EU region" tiers mean you rent capacity — you don't hold the data.
- Prompts and uploaded files transit to, and are processed on, the provider's cloud — outside your control boundary.
- You cannot fully evidence the data-governance, representativeness, and quality practices the AI Act expects when the processing pipeline isn't yours.
- Cross-border processing reopens GDPR Chapter V transfer risk (post-Schrems II) for every regulated record.
- "Trust us, we don't train on your data" is a contract clause, not an architectural guarantee.
Art. 10 — Data and data governance · reinforced by Art. 26 — Obligations of deployers · and GDPR Chapter V (international transfers).
The Emblema solutionEmblema deploys entirely on your infrastructure. The data physically lives in stores you run, and inference runs on your hardware by default.
- All data sits in your containers — PostgreSQL /
postgres-vector, Milvus (vectors), MinIO (objects), Redis, Neo4j — stood up byinstall.sh/docker-compose-data-source.yaml. - Embeddings are computed locally (BGE-M3, 1024-d, via
vllm-bge-m3) and reasoning runs on a local LLM by default (e.g. Qwen via LiteLLM); cloud model keys are empty unless you opt in. - Air-gap capable — full single-node or multi-node deployment with no mandatory egress (
scripts/swarm/). Your data never leaves your network, not even to us. - Drive sync is metadata-only — your source files stay where they live; nothing is migrated or copied out.
The audit trail is built in, not bolted on
Lifetime, tamper-evident records of what the system did.
High-risk AI has to keep automatic logs over its lifetime, and deployers have to retain them. A SaaS dashboard is not a tamper-evident record you can hand an auditor.
With a hosted LLM service, the logs you need live on the provider's side: you get usage dashboards, not an immutable, lifetime event record. Retention is set by the vendor, immutability isn't guaranteed, and you can't reconstruct the full chain of "who asked what, which data was retrieved, what was produced" on demand.
- Event logs are provider-controlled and provider-retained — you can't guarantee they exist when you need them.
- No write-once / immutability guarantee, so the record isn't defensible against the "was it altered?" question.
- Reconstructing a complete decision trail across a black-box API is largely impossible.
Art. 12 — Record-keeping · Art. 19 — Automatically generated logs · Art. 26(6) — deployer log retention.
The Emblema solutionEmblema ships a real audit subsystem (apps/www-emblema/lib/audit/index.ts) with dual-sink persistence and privacy-by-design.
- Searchable + immutable: every event is structured-logged to Loki (default 6-month retention) and written as a per-event JSON object to MinIO — WORM-ready: configure the bucket with S3 Object Lock (COMPLIANCE mode) and the record becomes immutable.
- Privacy-by-design: the immutable store keeps only a salted hash of the user ID and an IP truncated to /24 — raw identifiers stay in the operational log within retention.
- Durable execution history: every Workspace run is a Temporal workflow with queryable history (
workspace-service/app/temporal/workflows.py); every graph node is inspectable and re-runnable — the trail is structural. - Emblema ships with a documented compliance-policy set (
docs/compliance/) rather than leaving governance as an exercise for the buyer.
You can document — and explain — a system you can actually see
Technical documentation and the right to explanation.
High-risk AI requires detailed technical documentation and interpretable outputs. You cannot author either for a model whose internals are a trade secret and whose behaviour changes silently behind an API.
OpenAI, Anthropic, and Google ship closed frontier models: architecture, training data, and evaluation methodology are undisclosed, and the model can be updated underneath you without notice or version guarantees. You depend on the provider's documentation — which may not satisfy your Annex IV obligation — and you can rarely trace a given output back to a source.
- You can't compile Annex IV technical documentation for a system you're not allowed to inspect.
- Silent model updates break reproducibility and version stability.
- "Why did it answer this?" has no traceable answer when retrieval and generation are opaque.
Art. 11 + Annex IV — Technical documentation · Art. 13 — Transparency and provision of information to deployers.
The Emblema solutionEmblema runs open-weight, operator-chosen models inside an inspectable resource-graph — and every grounded answer carries its receipts.
- Open, documentable models (Qwen, BGE-M3,
gpt-oss) you select and can describe — pin a version, document it, keep it stable. - Citations on every RAG answer: the
dataSourcePartschema (schema/chat-stream.ts) attaches source document, knowledge base, vector similarity score, and reranker score to each cited chunk, rendered as clickable references (lib/remark-citations.ts) — a literal right to explanation traceable to the exact text. - Model provenance per message:
llmIdrecords the exact model that produced each response — names collide, IDs don't. - Every node is deterministic and inspectable, so the system's behaviour is documentable rather than emergent.
A human can stop it — at any node, mid-flight
Human oversight designed into the graph.
High-risk AI must be effectively overseeable: a person needs to intervene, override, or stop it. Autonomous SaaS agents run forward-only, and "stop" means closing the tab.
Agentic products from the major vendors execute a chain end-to-end. You can't insert a mandatory human checkpoint inside the vendor's loop, you can't halt a single step without killing the whole run, and there's no clean override point — which is exactly what Article 14 demands.
- No built-in intervention points inside a vendor's autonomous chain.
- "Stop" is all-or-nothing; you can't pause or cancel one step while others continue.
- Automation bias is hard to counter when the process is forward-only and opaque.
Art. 14 — Human oversight.
The Emblema solutionEmblema orchestrates work as a Temporal-driven graph with real human-in-the-loop control (workspace-service/app/temporal/workflows.py).
- Inspect the plan before it runs — the execution plan (DAG) is generated and reviewable before any commit.
- Per-node cancellation signals — stop one node while its siblings keep running; downstream nodes auto-cancel.
- Explicit status state machine — PENDING → RUNNING → COMPLETED / CANCELLED / FAILED, queryable live.
- Deterministic atomic nodes a human can verify and re-run independently — oversight isn't bolted on, it's how the graph works.
Your security perimeter is yours
Accuracy, robustness, and cybersecurity inside your walls.
High-risk AI must reach an appropriate level of robustness and cybersecurity and resist tampering. On multi-tenant cloud, you can't audit the posture or guarantee the isolation.
Hosted LLM services are multi-tenant, your data is in transit to the provider's regions, and you can't audit the provider's security posture or guarantee isolation between tenants. The attack surface now includes the vendor and the network path — neither of which you control.
- Shared, multi-tenant infrastructure you can't inspect or harden.
- Data crosses the network to third-party (often third-country) regions in normal operation.
- No way to independently verify resilience against data/model poisoning or adversarial inputs on the provider side.
Art. 15 — Accuracy, robustness and cybersecurity.
The Emblema solutionEverything runs inside your perimeter, behind your IAM, on your network.
- TLS 1.2+ with modern, forward-secret ciphers at the edge (Traefik,
config/traefik/dynamic/tls.yml,sniStrict). - Keycloak IAM for users and JWT service-to-service auth (
getAppToken,packages/data-core/lib/keycloak.ts). - Network isolation — only the reverse proxy exposes 443; data stores (Milvus, PostgreSQL, Redis) have no external ports by default (
emblema/emblema-clusternetworks). - Single-tenant and air-gappable — your SOC owns the posture end to end.
You choose the model — and you can prove which one answered
General-purpose-model control, provenance, and no lock-in.
Build on someone else's general-purpose model and you inherit obligations you can't satisfy — because you can't see the model's provenance, and you're tied to one provider's roadmap.
When you build on a closed general-purpose AI model, you depend on the provider's compliance for training-data provenance, copyright policy, and documentation — none of which you can verify. You also can't tell whether the model crosses the systemic-risk compute threshold that triggers the heaviest obligations, and you're locked to one vendor's pricing and release cadence.
- You inherit downstream GPAI obligations while having zero visibility into provenance or copyright handling.
- No control over whether you're standing on a systemic-risk-class model.
- Vendor lock-in: one provider's roadmap, one provider's price.
Art. 53 — Obligations for providers of general-purpose AI models · Art. 55 — GPAI models with systemic risk.
The Emblema solutionModels are operator-configurable through a declarative registry (config/litellm/config.yaml) — no lock-in, full provenance.
- Local open-weight defaults (Qwen, BGE-M3,
gpt-oss) you can document and govern; cloud models are optional, gated behind explicit API keys. - Swap any model in one line — LiteLLM fronts 100+ providers, so you're never married to a single vendor.
- Right-size deliberately — choose models that keep you below systemic-risk thresholds when that's the safer posture.
- Per-message
llmIdprovenance records exactly which model produced each output.
You can actually pass a deployer audit
Deployer accountability and real impact assessments.
As the deployer, you're on the hook regardless of vendor — but you can only assess and monitor what you can see. A fundamental-rights or data-protection assessment over a black box is theatre.
The AI Act puts obligations on the deployer: use the system per instructions, ensure oversight, monitor operation, keep logs, and inform affected people. With a hosted service you have no levers to do any of that meaningfully, and a Fundamental Rights Impact Assessment over opaque, offshore processing is largely performative.
- No operational levers to monitor, log, or constrain a third-party service.
- A FRIA / DPIA over a black box can't produce a credible evidence base.
- "Who did what to which record" is unanswerable when access control lives in the vendor's product.
Art. 26 — Obligations of deployers · Art. 27 — Fundamental rights impact assessment.
The Emblema solutionMonitoring, logging, oversight, and data locality are all in the operator's hands — and access is governed and recorded.
- Fine-grained permissions at Entity and Record level for Users, Service Accounts, and Groups (
packages/data-core/types/permissions.ts). - Enforced and recorded: the
withApiOperationmiddleware (utils/api-middleware.ts) validates the entity chain and writes the result — who, what action, which resource, allowed/denied, duration — into the audit trail. - A real evidence base for a FRIA / DPIA: data location, processing logic, oversight controls, and access records are all inspectable in your estate.
- Demonstrable accountability to a supervisory authority, because the whole system is yours to show.
Disclosure and content-marking as an enforced policy, not an afterthought
Transparency for AI interaction and synthetic content.
The AI Act requires that people know when they're dealing with AI, and that synthetic content be marked. Spread your AI across a dozen SaaS tools and consistent enforcement becomes impossible.
Article 50 requires disclosing AI interaction (e.g. chatbots) and machine-readable marking of synthetic audio, image, video, and text, plus labelling of deep fakes. When AI features are scattered across many disconnected SaaS products, applying one disclosure-and-marking policy uniformly and verifiably is a manual, error-prone afterthought.
- No central control point to apply disclosure and content-marking consistently.
- Each tool handles (or ignores) synthetic-content marking its own way.
- Deep-fake / synthetic-media labelling becomes a per-tool checklist instead of a guarantee.
Art. 50 — Transparency obligations for providers and deployers of certain AI systems.
The Emblema solutionBecause everything flows through one orchestration layer, disclosure and content-marking can be expressed as an enforced node in the deterministic graph — applied uniformly to generated artifacts rather than left to each tool.
- A single policy point where AI-interaction disclosure and synthetic-content marking are applied across outputs.
- Policy-as-node: the rule runs as part of the graph, so it's consistent and inspectable.
- Honest scope note: this is policy-enablement the architecture makes straightforward — a central place to enforce labelling — rather than a turnkey watermarking product today. It's ranked last for exactly that reason.
One root cause. One architectural answer.
The competitors' problem is architectural: a hosted, closed model means the data, the logs, the model internals, and the control points all live somewhere you can't reach. Emblema's answer is also architectural: a self-hosted, deterministic, inspectable resource graph emits the data residency, the audit trail, the citations, the model provenance, and the oversight hooks regulators ask for — as a byproduct of using it.
That's why the benchmark numbers matter beyond cost: a graph that is ±3% deterministic (versus ±13% for a free-running agent) is a graph you can reproduce, inspect, and defend. Reproducibility is auditability.
Compliance is an output of the deterministic graph — not extra work bolted on after.
Why this ranking
- 1Art. 10Data sovereignty — The gating decision for every regulated buyer; if data leaves the building, nothing else matters.
- 2Art. 12/19/26Record-keeping — The most concrete, code-backed differentiator: a real WORM-ready audit subsystem.
- 3Art. 11/13Transparency & documentation — Open models + citations turn "explainability" from aspiration into a feature.
- 4Art. 14Human oversight — Per-node cancellation is a capability competitors structurally lack.
- 5Art. 15Cybersecurity — Perimeter control is the natural consequence of self-hosting.
- 6Art. 53/55GPAI control — Model choice and provenance; strong, but a layer above raw data residency.
- 7Art. 26/27Deployer accountability — Synthesises sovereignty + logging + permissions into "passing the audit".
- 8Art. 50Synthetic-content transparency — Real obligation, but policy-enablement rather than a shipped feature — hence last.
Article index
Regulation (EU) 2024/1689| # | Topic | Article(s) |
|---|---|---|
| 1 | Data sovereignty & governance | Art. 10 (+ Art. 26; GDPR Ch. V) |
| 2 | Record-keeping, logging & traceability | Art. 12, Art. 19, Art. 26(6) |
| 3 | Transparency & technical documentation | Art. 11 + Annex IV, Art. 13 |
| 4 | Human oversight | Art. 14 |
| 5 | Accuracy, robustness & cybersecurity | Art. 15 |
| 6 | GPAI model control & provenance | Art. 53, Art. 55 |
| 7 | Deployer accountability & impact assessments | Art. 26, Art. 27 |
| 8 | Synthetic-content & interaction transparency | Art. 50 |
This content is informational and reflects how Emblema's architecture supports EU AI Act and GDPR obligations; it is not legal advice. Regulatory classification (e.g. whether a given use is "high-risk") depends on the deployment, and obligations should be confirmed with qualified counsel. Capability notes reference the Emblema codebase as of this draft; "optional" features (e.g. cloud model backends, MinIO Object Lock configuration) require operator configuration.