AI governance consulting — and our own governance, stated plainly.

Most AI governance consulting produces a policy document that describes an ideal company rather than yours, and is opened exactly once. Working governance is four concrete things: an inventory of the AI tools actually in use — not the ones that were approved — written boundaries on which data may reach which model, named points where a human signs before output executes, and a log that lets you reconstruct any decision later. We write those four things against your real workflows, and we build the gates and logs where building is needed.

This page has a second job. If you are vetting us — a security review, a vendor questionnaire, procurement counsel asking whether the development firm using AI has an answer for it — the OURS cards below are that answer: which tools touch client code, what is and is not placed in a model's context, our no-training position, and the name of the person who reads AI-generated output before it ships. A vendor that sells governance and cannot state its own is telling you what its documents are worth.

The failure mode in this category is thickness. A forty-page framework nobody can follow governs nothing; the transcription bot sitting silently in your client calls was never in it anyway. Rules people actually follow are short, name real tools, and attach to the moments where something irreversible happens — money out, a customer contacted, a record deleted, code merged.

If a written policy is genuinely all you need, we will say so on the call — some governance work is an afternoon of writing, not an engagement, and paying consulting rates for a template helps nobody.

Talk to Anupam →Fixed fee, scoped in writing before anything starts. No hourly billing, no verbal scope.

Scope

What governance covers — yours, then ours.

YOURS

A tool inventory that matches reality

Governance starts with what is actually running, not what was approved. The gap between the two is where incidents live: the browser extension that reads every page, the meeting bot recording client calls, the free-tier account someone opened with a work email. We list what is in use, what each tool can see, and under which terms it operates.

YOURS

Data boundaries, written down

Which classes of data may reach which model under which contract — and which may not, ever. Customer PII, credentials, unreleased financials and anything covered by someone else's NDA sit on the far side of the line. A boundary that lives in one engineer's head is not a boundary; it is a habit that leaves when they do.

YOURS

Human gates and audit trails

The points where a person signs before AI output executes — payment released, customer contacted, record deleted, code merged — and a log of what the model saw and produced at each one. When an auditor, an insurer or a customer asks why the system did what it did, the answer comes from the log, not from memory.

OURS

Our stack, disclosed

Client code is worked on with Claude Code under commercial terms that exclude customer content from model training; where a provider exposes a training setting, it is off. Production data, customer PII and live credentials are not placed in model context — secrets stay in environment stores the model never reads. Retention follows the provider's commercial terms, and we supply tool names, terms versions and settings in writing on request.

OURS

A named human before anything ships

Anupam Shah reads AI-generated output before it reaches a client repository. Not a policy asserting that review happens somewhere — a person whose name is on the approval, and the same person you will be speaking to on the call. Accountability that cannot be attached to a name is not accountability.

What buyers and reviewers ask.

What does AI governance consulting actually produce?

Short documents and working mechanisms, not a framework binder. On paper: a page per tool stating what it can see and under which terms it runs, a matrix of which data classes may reach which model, and a review map with a name against each gate. Where enforcement needs code, we build the gate and the log into the system itself. AI governance consulting that ends at a PDF has done half the job; a rule that is not wired into the moment it governs is a suggestion.

Does our code or data train your models?

No. The tools we use to write and review code run under commercial terms that exclude customer content from model training, and where a provider exposes a training toggle it is off. If your security review needs specifics — tool names, terms versions, settings — we provide them in writing. That is a normal ask, and a vendor who will not answer it is answering it.

Who reviews AI-generated output before it ships?

Anupam Shah, by name. AI writes a large share of the code we produce — a firm claiming otherwise today deserves your skepticism — and none of it reaches a client repository without a human reading it first. The review is not ceremonial: generated code fails in patterns a reader has to know to catch, like handling the documented case and inventing the undocumented one.

Which AI tools touch our code, and what do they see?

Claude Code is the implementation tool; it sees the working repository and the specifications we write for it, because that is what implementation requires. It does not see your production database, your customers' personal data, or your credentials — secrets live in environment stores outside model context, and live data stays in your infrastructure. If an engagement ever genuinely required an exception, it would be agreed with you in writing first, not discovered later.

Do we need an AI governance framework if we're a small company?

You need one the day AI output can reach a customer, move money, or touch regulated data — headcount is irrelevant to that. What changes with size is weight: a small firm's AI governance framework is a few pages naming real tools and real gates, not a committee structure. If your actual exposure is low, the honest version of this engagement is short, and we will tell you that on the call rather than sell you ceremony.

Is this legal or regulatory compliance advice?

No — we are not lawyers and do not sell legal advice. What regulation keeps demanding, though, is operational: inventories of AI systems, human oversight at decision points, records of what a model did and why. We build that layer — the artifacts and mechanisms your counsel maps to whichever regime applies to you. When a question is genuinely legal, we say so and it goes to your lawyer, not into our scope.

Can you complete our vendor security questionnaire?

Yes, in writing, with the specifics the OURS cards above summarise — tools, terms, data handling, retention, review. An AI governance policy you can hand to procurement is one of the deliverables this service sells, so writing our own was the obvious first test of whether we should sell it at all. This page is the short version; the long version arrives when you ask.

Bring the questionnaire. You'll get answers in writing.

Anupam Shah

Founder · he answers these himself

Book a call →

Fixed fee, scoped in writing before anything starts. No hourly billing, no verbal scope.

Related: AI consulting & implementation · LLM & RAG integration · Staff augmentation · How we work