# Akumi vs calling the provider yourself Pointing your SDK at OpenAI or Anthropic is the fastest prototype and the hardest compliance review. Akumi keeps the same call and moves the hard parts into the platform. ## 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. ## 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. ## What changes when the review starts. - Time to first token. Akumi: One base_url change and a key. The same SDK, the same code, the same afternoon. Direct to provider: A key and you are running, until the first compliance question arrives. - Where the data goes. Akumi: EU-resident models by default. Non-EU routing is blocked at a fail-closed guard unless you allow it explicitly. Direct to provider: Straight to a US provider on every request, whatever the prompt happens to contain. - Personal data. Akumi: Pseudonymized before egress by the firewall, restored in your response. Direct to provider: Whatever your prompt contains is what the provider receives. - Audit trail. Akumi: Metadata-only record of model, provider, region and services for every request, retained on your policy. Direct to provider: Provider dashboards, built for billing rather than for a data protection officer, and nothing tying a request to a region. - Retrieval and memory. Akumi: Conversation memory and your documents share one knowledge graph behind the same endpoint, and an answer arrives with the sources it used. Direct to provider: Yours to build: a store, an embedding pipeline, a chunking strategy, retrieval code, and the isolation logic holding it all apart. - Billing and contracts. Akumi: One EU vendor, one invoice, and usage attributed per request and per service. Direct to provider: A contract, a key and an invoice per provider, with no per-request attribution across them. - Switching models. Akumi: Change a string. The router handles fallback, and provider differences are absorbed behind one schema. Direct to provider: A new SDK, new auth, new payload shape and new error handling for every provider you add. ## 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. - Who processes the data. Akumi: An EU-resident provider, on EU infrastructure, by default. Direct to provider: A US-headquartered processor, whichever region you selected. - Transfer paperwork. Akumi: Not triggered on the default path, because nothing leaves the EU. Direct to provider: A lawful basis, a DPA and SCCs for every request carrying personal data. - Turning on external models. Akumi: An explicit, recorded decision, enforced by a guard that fails closed. Direct to provider: The default, and the only, behaviour. ## 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. - Personal data. Akumi: Pseudonymized before egress, restored in your response, on by default. Direct to provider: Your code, your regexes, your maintenance. - Repeated questions. Akumi: Exact and semantic response cache, so a near-duplicate skips the inference charge. Direct to provider: Billed again, every time. - Where it ran. Akumi: Recorded per request: model, provider, region and services, metadata only. Direct to provider: A billing dashboard, which is not the same artefact. ## 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. - Adding a provider. Akumi: Change a string. Fallback and provider differences are absorbed by the router. Direct to provider: A new SDK, new auth, new payload shape, new error handling. - Contracts and invoices. Akumi: One EU vendor, one agreement, one invoice. Direct to provider: One of each, per provider. - Usage visibility. Akumi: Attributed per request and per service across every provider. Direct to provider: Per provider dashboard, with no view across them. ## 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. ## 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? - Azure OpenAI: /compare/azure-openai - Self-hosting open models: /compare/self-hosted - Aimable: /compare/aimable - Zylon: /compare/zylon ## 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.