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.
Going direct is the right first move and almost everyone makes it. You have an API key, an SDK you already know, and a working prototype by the end of the day. Nothing here argues with that.
The problem arrives later, and it is never the code. It is the review: 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 DPO to approve, and an EU AI Act exposure you cannot wave away. Meanwhile the things you assumed you would add later, pseudonymization, retrieval that keeps one customer out of another customer's answers, an audit trail a regulator would accept, are all still unwritten. Akumi keeps the call you already wrote and moves that layer into the platform.
An EU-sovereign AI platform behind one OpenAI-compatible endpoint. EU-resident models answer by default, a PII firewall pseudonymizes personal data before anything leaves, a guard scans prompts and tool output, 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.
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.
| 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 PII firewall, restored in your response. | Whatever your prompt contains is what the provider receives. |
| Audit trail | Metadata-only record of model, provider, region and modules for every request, retained on your policy. | Provider dashboards, built for billing rather than for a DPO, and nothing tying a request to a region. |
| Retrieval and memory | Conversation memory and your documents share one knowledge graph behind the same endpoint, so an answer follows the link from a user to their organization to the document that answers them, and arrives with the sources it used. | Yours to build: a store, an embedding pipeline, a chunking strategy, retrieval code, and the tenant isolation logic holding it all apart. |
| Billing and contracts | One EU vendor, one invoice, and usage attributed per request and per module. | 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. |
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. Sending personal data to a US-headquartered provider remains a transfer that needs a lawful basis, a data processing agreement and standard contractual clauses, and it stays a Schrems II conversation however European the endpoint looks.
Akumi answers on EU-sovereign 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 a request only leaves the EU when the payload is firewalled or a compliance acknowledgment has been recorded against it. 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-sovereign 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. |
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, catching prompt injection before a tool call acts on it, storing and retrieving your own documents without leaking one tenant into another's answers, caching repeated questions so you stop paying twice, 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. On Akumi they are modules on the same request, each metered separately so you can see what governance actually costs. 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. |
| Prompt injection | Guard scans prompts and tool output every turn and fails with a typed error you can branch on. | Nothing by default. Tool output is trusted unless you make it otherwise. |
| 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 modules, metadata only. | A billing dashboard, which is not the same artefact. |
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.
Akumi puts them behind one OpenAI-compatible schema with one key, one bill, and a router that handles fallback. Adding a provider is a string, not a sprint, and usage stays attributable per request and per module across all of them.
| 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 module across every provider. | Per provider dashboard, with no view across them. |
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 if you would rather use those.
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. Akumi answers on EU-sovereign models by default, so that transfer does not occur on the default path.
Yes, under an explicit routing policy. External models are off by default and reaching one requires either a firewalled payload or a recorded compliance acknowledgment. The egress guard fails closed, so it never happens silently or by misconfiguration.
A PII firewall that pseudonymizes before egress and restores afterwards, a guard against prompt injection that also scans tool output, 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 recording the model, provider and region for every call.
Per token, yes: inference is metered in credits at a markup over provider cost, which pays for EU-sovereign serving, the governance modules 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 governance layer themselves.
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.
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.
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.
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.
We use privacy-friendly, EU-hosted analytics to understand how Akumi is used. Accept analytics cookies, or continue without them. See our cookie policy.
