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 — and written boundaries on which data may reach which model.
Then 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.
We publish our own governance below: which tools touch client code, what stays out of model context, our no-training position, and the gate AI-generated code passes before merge.
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.
Scope
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.
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.
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.
We build client code 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 stay out of model context — secrets live 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.
AI writes a large share of the code we produce. None of it merges into a client repository until a person has read it: a merge is one of the irreversible moments this page names, and it gets the gate we sell.
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.
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, such as tool names, terms versions and settings, we provide them in writing. A vendor who will not answer that is answering it.
We implement with Claude Code. It sees the working repository and the specifications we write for it, because implementation requires them.
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. Any exception is agreed with you in writing first.
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: an AI governance framework for a company your size is a few pages naming real tools and real gates, not a committee structure.
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. Legal questions go to your lawyer.
Yes, with the specifics summarised above: tools, terms, data handling, retention, review. An AI governance policy you can hand to procurement is one of this service's deliverables, and we hold one ourselves. This page is the short version; the full policy is available on request.
A fixed fee against written scope, agreed before work starts and billed at milestones as the work lands.
You do, outright. IP assignment is signed before repository access, by everyone who touches the code, and it covers AI-assisted output. Handover includes the runbook and the rollback path. Nothing depends on a licence we control.
Retainers end on 30 days written notice from either side, with no minimum term. Milestone billing means you never pay ahead of delivered work.
Founder, Provingmark
Thirty minutes, no charge.
Related: AI consulting & implementation · LLM & RAG integration · Staff augmentation · How we work