Production-grade AI · Built to a regulated standard

Anyone can demo AI. We build the AI you can put into production - and prove it.

We design and build AI applications that go into production: tenant data isolated by the database, every model and persona versioned and evaluated, no egress you didn’t configure. Then we hand you the code, and hand your reviewer the isolation report that shows it.

Self-hostable Multi-tenant capable Governed & evaluated Yours to own

Most AI software is a demo that happens to be running in production.

It leaks data across tenants, can’t say which model decided what, runs on someone else’s cloud, and stalls the moment it meets a security questionnaire.

We build the opposite, and the difference is structural rather than cosmetic. Ask any vendor for their cross-tenant isolation report; ours regenerates on demand, against every deployment, including yours.

Why it passes a security review

The four things we get right

The boring parts. Also the parts that decide everything.

These decide whether the project survives infosec, the auditor, and the second year of production.

01

Isolation by the database.

Tenant data is separated by PostgreSQL row-level security, enforced one layer below the application, where a single coding mistake can’t quietly defeat it. We ship a cross-tenant test suite that proves it, table by table.

02

Self-hosted by default.

It runs on your infrastructure. Your data, your prompts, your audit logs never have to leave your control. Built for data-residency and sovereignty requirements, not retrofitted for them. And self-hosted doesn’t mean self-operated. If you’d rather not run it yourself, our managed service operates it for you, under an SLA.

03

Governed and evaluated.

We don’t prompt and pray. Every model and every AI persona is versioned, tested against a defined evaluation set, and logged. You can show which version of what behaviour was live on any given day.

04

Built to be owned.

You get the source, on your servers, with the architecture documented. No lock-in to a SaaS you can’t audit and can’t leave.


“Which model wrote this, and under what policy?”
In our systems, that’s a query.

Security & assurance

Architecture notes for a sceptical reviewer.

Every regulated buyer has the same five questions about an AI system. We wrote the long-form answer to each, in the language a security reviewer would use and free of marketing.

Read the security review notes
KATEMBA - ASSURANCE NOTES REF. KTB-SR-01 Why it passes a security review 1. Tenant isolation, enforced below the application 2. It runs where you do 3. Everything significant is logged 4. Governed models, not loose prompts 5. You can leave Written to be useful to a reviewer reading alone.

Questions

Asked often.

Who is this for? +

Regulated organisations that need AI in production and can’t accept a SaaS where one customer might see another’s data, where data leaves their cloud, or where they can’t audit what changed and when.

Do you have to run on my infrastructure? +

That’s the default. We can run a managed instance for you under a managed-run agreement if you prefer, but the architecture is built for your servers first.

What do you mean by “governed”? +

Every AI persona - the way an assistant or agent should behave - is version-controlled, tested against an evaluation set before it goes live, and logged when it acts. You can show, at any point, what was live and what it did.

Do we own the code? +

Yes. Source in your repos. Architecture documented. No proprietary runtime you can’t leave.

Tell us what you’re trying to put into production.

We’ll tell you straight whether we’re the right team.