Introducing OBEL GaaS: Governance-as-a-Service

Every AI product eventually has the same conversation with a customer's security team. What happens to sensitive data before it reaches a model. Who decided a request should be blocked, and against what rule. Can you prove your audit record hasn't been quietly edited after the fact. Most platforms answer that conversation with a roadmap slide, because building scrubbing, classification, policy enforcement, and an audit trail well is slow, and it is not the product they set out to build.

We built all four inside OBEL already, because we had no choice - a governance platform that cannot answer those questions about its own traffic is not a governance platform. Today we are exposing that same stack as an API. We are calling it OBEL GaaS, and the pitch is short: we are cooking with GaaS. Are you?

Four engines, not a feature flag

GaaS is not a stripped-down trial of the OBEL product. It is four of OBEL's own governance engines, exposed directly.

• Scrubbing - the same ARGUS-i detection engine that runs against every prompt inside OBEL's own production traffic, available as a scrub call against any text your platform handles.
• Classification and access control - PSPF-aligned levels from UNOFFICIAL through TOP SECRET, with a hard per-org ceiling on what classification can be read or retained, enforced at the API layer regardless of what your own application code does.
• Policy engine - rules matched on event type, risk tier, and resource type, most specific match wins, with effects of allow, warn, block, or require approval. Orgs without custom rules fall back to a simple risk-tier threshold.
• Audit ledger - every governance decision is hash-chained, not just written to a log table. The chain verification algorithm is published, so you or your customers can independently confirm nothing was altered after the fact.

Why this is not a self-serve add-on

GaaS is deliberately not the next tier on the pricing page. It is sold and priced the way infrastructure gets sold: usage-based, sales-assisted, integrated directly with the platforms that embed it. A platform vendor building a claims tool, a legal workflow product, or an internal AI assistant is not the same buyer as an individual developer reaching for an API key on a whim, and treating it that way would undersell what four production-grade governance engines are actually worth to a B2B2B partner.

It also runs on its own infrastructure. GaaS traffic is served from api.useobel.ai, a separate application from OBEL's own product surface, with its own deployment pipeline and its own scaling. A bad GaaS deploy cannot take down app.useobel.ai, and a spike in a partner's call volume cannot degrade OBEL's own users. API keys are scoped, too - a key issued for GaaS cannot reach OBEL's own Developer-tier proxy, and vice versa. Isolation is not a diagram on a slide; it is enforced at the key level, on every request.

What it looks like in practice

One call: send text, get back the cleaned version, a structured list of what was found, and a hash-chained audit event appended to your org's ledger automatically. No separate logging call, no second integration for compliance evidence - the audit record is a side effect of the same request, not a feature you have to remember to wire up.

Policies and access ceilings layer on top of the same key. A platform can let its own customers configure their risk-tier thresholds and classification ceilings through their own admin surface, and every governed request against that org's key respects those settings without the platform having to re-implement policy evaluation itself.

“We didn't build GaaS to sell a smaller slice of OBEL. We built it because the four hardest parts of AI governance are already solved inside our own platform, and every serious AI product is going to need them eventually - whether they build them or borrow ours.”

- Denis Bouton

Denis Bouton is the founding Chief Architect of OBEL™ and Managing Partner at ninthLABS Ventures, where he advises Post-Sales Services and Customer Success organisations on scaling onboarding, adoption, and retention. He leads OBEL's product and platform strategy.