Comparison
Akumi vs calling the provider yourself
Pointing your SDK straight at OpenAI or Anthropic is the fastest way to a working prototype, and it is exactly what most teams do first. The bill comes due at the compliance review: a US processor, a transfer to defend, no pseudonymization, and an audit trail you have to build. Akumi keeps the same call and moves the hard parts into the platform.
The prototype is easy. The review is not.
Going direct is the right first move and almost everyone makes it. The problem arrives later, and it is never the code. Your prompts carry client matters, patient records or financial personal data, and every one of them is being sent to a US processor. That is a transfer to justify, a sub-processor for your data protection officer to approve, and an EU AI Act exposure you cannot wave away. Meanwhile the things you assumed you would add later are all still unwritten.
The two things being compared
What each one actually is.
One of them is a platform and one of them is a completion. Most of this page is about the distance between the two.
Akumi
An EU-resident AI platform behind one OpenAI-compatible endpoint. EU-resident models answer by default, a firewall pseudonymizes personal data before anything leaves, retrieval and per-user memory sit behind the same call, and every request is recorded in a metadata-only audit trail. Migration from a direct integration is a base_url and a key.
Going direct
Your application calls OpenAI, Anthropic or Google itself. You hold one API key and one contract per provider, you get their SDK, their model line-up on launch day, and their list price with nobody in between. Everything above the completion, residency, redaction, retrieval, isolation, audit, is your application's responsibility.
Side by side
What changes when the review starts.
| Dimension | Akumi | Direct to provider |
|---|---|---|
| Time to first token | One base_url change and a key. The same SDK, the same code, the same afternoon. | A key and you are running, until the first compliance question arrives. |
| Where the data goes | EU-resident models by default. Non-EU routing is blocked at a fail-closed guard unless you allow it explicitly. | Straight to a US provider on every request, whatever the prompt happens to contain. |
| Personal data | Pseudonymized before egress by the firewall, restored in your response. | Whatever your prompt contains is what the provider receives. |
| Audit trail | Metadata-only record of model, provider, region and services for every request, retained on your policy. | Provider dashboards, built for billing rather than for a data protection officer, and nothing tying a request to a region. |
| Retrieval and memory | Conversation memory and your documents share one knowledge graph behind the same endpoint, and an answer arrives with the sources it used. | Yours to build: a store, an embedding pipeline, a chunking strategy, retrieval code, and the isolation logic holding it all apart. |
| Billing and contracts | One EU vendor, one invoice, and usage attributed per request and per service. | A contract, a key and an invoice per provider, with no per-request attribution across them. |
| Switching models | Change a string. The router handles fallback, and provider differences are absorbed behind one schema. | A new SDK, new auth, new payload shape and new error handling for every provider you add. |
- Time to first tokenAkumiOne base_url change and a key. The same SDK, the same code, the same afternoon.Direct to providerA key and you are running, until the first compliance question arrives.
- Where the data goesAkumiEU-resident models by default. Non-EU routing is blocked at a fail-closed guard unless you allow it explicitly.Direct to providerStraight to a US provider on every request, whatever the prompt happens to contain.
- Personal dataAkumiPseudonymized before egress by the firewall, restored in your response.Direct to providerWhatever your prompt contains is what the provider receives.
- Audit trailAkumiMetadata-only record of model, provider, region and services for every request, retained on your policy.Direct to providerProvider dashboards, built for billing rather than for a data protection officer, and nothing tying a request to a region.
- Retrieval and memoryAkumiConversation memory and your documents share one knowledge graph behind the same endpoint, and an answer arrives with the sources it used.Direct to providerYours to build: a store, an embedding pipeline, a chunking strategy, retrieval code, and the isolation logic holding it all apart.
- Billing and contractsAkumiOne EU vendor, one invoice, and usage attributed per request and per service.Direct to providerA contract, a key and an invoice per provider, with no per-request attribution across them.
- Switching modelsAkumiChange a string. The router handles fallback, and provider differences are absorbed behind one schema.Direct to providerA new SDK, new auth, new payload shape and new error handling for every provider you add.
The residency question
An EU region is not an EU processor.
The usual first fix is to pick a European region and consider the residency question closed. It is not. Choosing a region changes where the compute sits. It does not change who is processing the data or under which jurisdiction, and sending personal data to a US-headquartered provider remains a transfer that needs a lawful basis, a data processing agreement and standard contractual clauses.
Akumi answers on EU-resident models by default, so the transfer does not happen in the first place. Where you do want an external model, that is an explicit decision rather than an accident: the egress guard fails closed, so the failure mode of a misconfiguration is a refused request, not a quiet export.
| Dimension | Akumi | Direct to provider |
|---|---|---|
| Who processes the data | An EU-resident provider, on EU infrastructure, by default. | A US-headquartered processor, whichever region you selected. |
| Transfer paperwork | Not triggered on the default path, because nothing leaves the EU. | A lawful basis, a DPA and SCCs for every request carrying personal data. |
| Turning on external models | An explicit, recorded decision, enforced by a guard that fails closed. | The default, and the only, behaviour. |
- Who processes the dataAkumiAn EU-resident provider, on EU infrastructure, by default.Direct to providerA US-headquartered processor, whichever region you selected.
- Transfer paperworkAkumiNot triggered on the default path, because nothing leaves the EU.Direct to providerA lawful basis, a DPA and SCCs for every request carrying personal data.
- Turning on external modelsAkumiAn explicit, recorded decision, enforced by a guard that fails closed.Direct to providerThe default, and the only, behaviour.
What you still owe
The SDK gives you a completion.
A provider SDK returns tokens. Everything that makes those tokens safe to put in front of a customer is yours: detecting and masking personal data on the way out and restoring it on the way back, storing and retrieving your own documents without leaking one tenant into another's answers, caching repeated questions, and recording enough about each request that someone can later answer where it ran.
Each of those is a few weeks the first time and a permanent maintenance surface afterwards, because models, attacks and regulations all keep moving. The honest version of this comparison is not that you cannot build it. It is that you will keep building it.
| Dimension | Akumi | Direct to provider |
|---|---|---|
| Personal data | Pseudonymized before egress, restored in your response, on by default. | Your code, your regexes, your maintenance. |
| Repeated questions | Exact and semantic response cache, so a near-duplicate skips the inference charge. | Billed again, every time. |
| Where it ran | Recorded per request: model, provider, region and services, metadata only. | A billing dashboard, which is not the same artefact. |
- Personal dataAkumiPseudonymized before egress, restored in your response, on by default.Direct to providerYour code, your regexes, your maintenance.
- Repeated questionsAkumiExact and semantic response cache, so a near-duplicate skips the inference charge.Direct to providerBilled again, every time.
- Where it ranAkumiRecorded per request: model, provider, region and services, metadata only.Direct to providerA billing dashboard, which is not the same artefact.
More than one provider
One provider is an integration. Four is a maintenance project.
Most teams do not stay on one provider. A cheaper model appears, a customer asks for something specific, an outage forces a fallback, and suddenly you are carrying several SDKs with different payload shapes, different auth, different error semantics and different rate-limit behaviour, plus the routing logic to choose between them and the contracts and invoices behind each.
| Dimension | Akumi | Direct to provider |
|---|---|---|
| Adding a provider | Change a string. Fallback and provider differences are absorbed by the router. | A new SDK, new auth, new payload shape, new error handling. |
| Contracts and invoices | One EU vendor, one agreement, one invoice. | One of each, per provider. |
| Usage visibility | Attributed per request and per service across every provider. | Per provider dashboard, with no view across them. |
- Adding a providerAkumiChange a string. Fallback and provider differences are absorbed by the router.Direct to providerA new SDK, new auth, new payload shape, new error handling.
- Contracts and invoicesAkumiOne EU vendor, one agreement, one invoice.Direct to providerOne of each, per provider.
- Usage visibilityAkumiAttributed per request and per service across every provider.Direct to providerPer provider dashboard, with no view across them.
The honest answer
The prototype was easy. This is the part that stalls.
Choose Akumi if
- The prototype worked and now legal, security or your data protection officer has to sign it off.
- Your prompts carry client matters, patient records, or financial personal data.
- You would otherwise be building pseudonymization, retrieval isolation, and an audit trail yourself.
- You want one EU vendor and one bill instead of a provider contract per model.
- You would rather your engineers shipped features than maintained four provider integrations.
FAQ
Questions people ask.
- Is it hard to move from OpenAI to Akumi?
- No. Akumi is OpenAI-compatible, so the migration is a base_url and a key. The same client library, the same request shape, the same streaming and tool-calling behaviour. There are also first-party SDKs for PHP, TypeScript and Python.
- Does using an EU region of OpenAI or Azure solve data residency?
- It solves where the compute runs, not who processes the data. A US-headquartered provider is still the processor, so a transfer of personal data still needs a lawful basis, a DPA and standard contractual clauses.
- Can I still use OpenAI or Anthropic models on Akumi?
- Yes, under an explicit routing policy. External models are off by default and reaching one requires either a firewalled payload or a recorded acknowledgment. The egress guard fails closed, so it never happens silently or by misconfiguration.
- What does Akumi add that a provider SDK does not?
- A firewall that pseudonymizes before egress and restores afterwards, retrieval and per-end-user memory on one knowledge graph, an exact and semantic response cache, per-request observability, and a metadata-only audit trail.
- Is Akumi more expensive than going direct?
- Per token, yes: inference is metered in credits, which pay for EU-resident serving, the services and one bill instead of several. Against that, the response cache removes the inference charge on repeated questions, and the comparison most teams actually care about is against the engineering time of building and maintaining the same layer themselves.
- Will my prompts be used to train models?
- No. Akumi is a processor acting on your instructions under a DPA, and the audit trail is metadata only: prompts, completions and retrieved content are never stored in it.
- How do I prove to an auditor where a request ran?
- From the log. Every request records the model, the provider and the region that served it, so residency is answered per request rather than by pointing at a policy or a region setting.
- Do I need to talk to sales?
- No. Signup is self-serve and pricing is published. You need a payment method before running inference, then a key and one base_url gets you a first response in minutes.
Weighing other options?
Keep the code, change the destination.
Akumi is OpenAI-compatible, so the migration is a base_url and a key. Start free, send a real request, and see what the audit trail gives you.