Your program works. It just takes more hours than you have.
The teams AI actually helps are the ones whose programs already run: the policies exist, the register is current, and the work still eats more of the week than it should. I set the rules for how your team uses AI on that work, and where the right answer is a tool that does not exist yet, I build it. What I build runs in your environment and belongs to you.
Four situations, four doors.
A standing program for how your team uses AI.
Your staff are already pasting things into chatbots, and a vendor has already added an AI feature to a system that touches patient data. With no decision written down, the tools get quietly banned or quietly adopted, and both of those are the same problem later. This is the program that says what is allowed, who approves it, and what happens when something goes wrong, so the work can actually get faster.
- AI acceptable-use policy
- AI vendor-management policy
- AI incident-response policy
- AI governance charter (committee, decision rights, cadence)
- AI contract rider (clauses for legal)
- Vendor landscape review & risk stratification
- Risk register & remediation roadmap
- Board-ready briefing deck
- Ongoing monitoring & advisory (optional)
Scoped per organization. Start with a conversation about where AI is already in use and what your team is trying to hand off.
Start a conversationTwo common entry points: For Healthtech (shipping AI into clinical workflows, stuck on enterprise review) and For Providers (under audit pressure with a shifting regulatory landscape).
The tool gets built, and you own it.
Sometimes the answer is not another policy. It is a piece of software that does the specific thing your organization does, in the way your organization does it. I wrote the platform my own practice runs on, which is the reason I can tell you what an automated pass will miss. That is the judgment I bring to building yours.
I do not build it on my platform. Doing that would be simpler for me, and it would open a licensing arrangement I could bill against for years. I do not do it, because the business should own its tools. What I build runs in your environment, in your accounts, under your control.
After the build, you decide how much of me continues. I can support it. I can maintain the analysis and the harness inside it. Or I can hand it over and you never call me again. All three are fine, and the third one is the point.
Scope is settled on the call, because what gets built depends on the work it is meant to absorb. Bring the task your team does most often and likes least.
Talk through a buildOne deal stuck in security review.
A single AI vendor is holding up an enterprise deal and you need a credible, documented answer fast, with no full posture review required. I review the vendor’s agreement terms, data flow, and subprocessor chain against HIPAA and return a Vendor Risk Report with a clear verdict: Compliant / Conditional / Non-Compliant, plus a remediation list to fix or require before signing.
If the review surfaces that your underlying documentation is the real gap, the fee credits toward the Risk Management Project that closes it.
Get a vendor verdictCommon questions.
It changes how much of the week the program costs. A working program still runs on people reading documents one at a time. The governance program decides what your team is allowed to hand to a model, who approves it, and what happens when it gets something wrong, so the tools can be used deliberately instead of quietly banned or quietly adopted.
You do, outright. It runs in your environment and in your accounts. I do not build it on my own platform, which would be simpler for me and would open a licensing arrangement I could bill against for years, because I think the business should own its tools. After delivery you decide whether I support it, maintain the analysis and harness inside it, or hand it over and never hear from me again.
When a single AI vendor is holding up an enterprise deal and you need a credible, documented answer fast, without a full posture review. I review that vendor against HIPAA and return a Vendor Risk Report with a Compliant / Conditional / Non-Compliant verdict and a remediation list. If the review surfaces that your own documentation is the real gap, the fee credits toward the Risk Management Project that closes it.
Both the governance program and a build are scoped per organization rather than sold at a fixed list price, because the deliverable set, the vendor footprint and the shape of a build vary widely. It is a conversation, not a checkout.
No. A current security risk analysis already has to address the AI tools in use, vendor AI access, and shadow AI, so the HIPAA Security Risk Assessment reads your AI surface as part of its scope. If you have never looked at that surface at all, start there. If you already have and the question is what to do next, start on this page.
The compliance skills behind this analysis are open source and free to run against your own documents, in your own environment. The platform I run them on is the instrument behind my delivery rather than a product sold here.
See the open-source skills →Bring me the task your team likes least.
Thirty minutes, no charge. Tell me where AI is already in use, what your team is trying to hand off, and what your program cannot afford to get wrong. I will tell you which of these three it is, and what it costs.