InferadaDocs
Portal
Introduction

About Inferada

Servada's managed LLM gateway — data governance, privacy, and per-organisation control on top of the raw model APIs.

What is Inferada?

Inferada is Servada's managed LLM gateway — an add-on that sits between your application and the language models you use, adding data-governance, privacy, and per-organisation control on top of the raw model APIs.

Between your application and the model, the gateway can:

  • Redact PII before it leaves. Names, emails, phone numbers, IDs are replaced with placeholders in the outgoing prompt; the real values are stitched back into the reply. Third-party providers never see them, and stored request history holds only the redacted form.
  • Keep sensitive workloads on Servada's local models.Restricted traffic can be pinned to a Servada-hosted LLM while non-sensitive traffic goes to a commercial provider. The rule lives in the gateway, not in each prompt writer — so no external provider ever receives data you've classified as restricted.
  • Isolate per organisation. Provider keys, tool configs, managed apps (Flowise, n8n, OpenWebUI), and request history are scoped to your org, not shared with other tenants. Secrets are encrypted at rest.

Spend and usage are visible and controllable from the portal: full request history, per-user and per-token spend, allowances, and caps. All self-service.

Request flow

Your applicationInferada gateway (Servada)• Auth + per-org scoping• PII redact → restore• Sensitivity-based model routing• Function-calling tools + processors• Spend + usage tracking• Audit log (PII-redacted)Servada local modelsrestricted trafficThird-party providersnon-sensitive only

Edge cases it covers

  • A contract forbids sending personal data to a US-based LLM. PII redaction + restoration lets you still use the best model without the compliance exposure.
  • Some workloads need to stay on Servada's local models, others can use commercial providers. Per-model routing enforces the split at the gateway instead of trusting the client.
  • Running multiple teams or customer organisations under one account, each with their own provider keys, configured tools, and usage caps — isolated by default.
  • A function-calling tool needs an API key (weather, CRM, an internal API). The key sits encrypted inside the gateway, scoped to the org that owns it; clients never handle it.