A practice for organisations building systems that hold sensitive data, or that cannot send work product to third-party model APIs. Greenfield software with identity, secrets, audit, and trust boundaries treated as first-class concerns from the first commit.
Most consultancies that advise on private AI have never shipped one. The first commit is where the threat model becomes architecture.
Security retrofits cost roughly ten times what security from line one costs. The arithmetic is honest and unflattering: adding identity, audit, and explicit trust boundaries to a system already in production is an archaeology project, not a refactor. The teams who lived through that bolt-on tend to wish, in retrospect, that the system had started where it eventually had to end up.
For organisations under privilege, HIPAA, or any regime where sending material to a third-party model API is a non-starter, the technical question is no longer whether to deploy privately. It is who can build the system you can defend on cross-examination — model selection, hardware sizing, retrieval that respects matter and ethical-wall boundaries, audit trails that an outside reviewer can read, and runbooks an in-house operator can run unattended.
We say that we build privacy by architecture, not by policy. The cybersecurity practice runs alongside this one because the same threat model that runs the assessment runs the build. Tulgra is the proof: a legal operating system, built under those constraints, that has not been retrofitted from a cloud-first product. The constraints survived contact with the work.
Greenfield engagements that ship to production. Identity, secrets, audit, and trust boundaries are first-class concerns from the first commit. We hand off code your team can read, extend, and own.
Threat modelling, architecture sketch, and a written design document agreed with the engineering lead. We name the data, the trust boundaries, and the failure modes before we write a line of code.
Weekly written updates. Production-quality code with tests, audit logging, and runbooks shipped alongside it. The engineering lead at the client sees the work in flight, not at the end.
A working session with the in-house engineering team to walk through architecture, security posture, operational playbook, and known follow-ups. The code lives with the client. We do not gate it behind a managed service.
Three-to-six-month engagements building software end-to-end. We ship to production, document the architecture, and hand off code your team can extend.
Threat modelling, design-document review, and reference architectures your engineers can act on without an interpreter.
On-premises and offline-first LLM deployment. Model selection, hardware sizing, data-flow analysis, and runbooks an in-house operator can run unattended.
Retrieval-augmented systems that keep your data inside your boundary. Document indexing, matter-aware query patterns, and review workflows.
Acceptable-use policy, data retention, and review processes for organisations deploying AI in regulated contexts. Drafted in writing, not by reference.
Legacy-system assessment, vendor shortlists, and sequencing plans for organisations modernising operational software.
Three engagements we have declined, and would decline again.
If the work requires a framework, language, or operational pattern the in-house team cannot read or run after we are gone, we say so before the engagement begins. The handoff is the test.
Karakor builds greenfield systems where security is a first-class concern from line one. Retrofitting identity, audit, and trust boundaries onto a system already in production is a different discipline. We refer.
Every model, every retrieval pattern, every governance decision comes with a written justification. If we cannot defend a choice against a partner's threat model — not against a vendor's pitch deck — it does not appear in the architecture.
We respond within two business days. Scoping calls are obligation-free and run thirty minutes.
