AI Governance

AI is a new vector for existing risks, not a new program. Govern it by extending the security controls you already have.

Start a Conversation

I help compliance-sensitive software companies govern the AI tools their teams are already using, without standing up a separate program. Usage policies, AI coding agent rules, integration security review, and risk assessment, built on the data classification, vendor risk, and acceptable use controls you already have.

AI isn't a new category of risk. It's a new vector for existing ones. Customer data exposure, credential leakage, vendor data handling, and model behavior in production are all problems a security program already addresses. AI governance points that work at a new surface area, and gets you an answer ready before a customer asks for it.

When Your Team Is Already Using AI Nobody Approved

It usually starts quietly. Developers are using ChatGPT, Copilot, and Claude. Nobody told them they could, and nobody told them they couldn't, so they assumed that if it wasn't prohibited, it was allowed. Around the same time, the sales team is using AI too. Drafting outreach, summarizing call notes, generating proposal language. The same assumption is running there. Useful tools, no rules, must be fine.

For a compliance-sensitive company, that's not fine, and the risk doesn't only live in the obvious places. It's not just customer schemas and production query results. It's the prospect list in the CRM, the notes from a sales call, the architecture diagram of a customer integration sitting in someone's OneDrive, the error log a developer pasted into a public tool to help debug. Every one of those is a potential vector, and the fastest way to lose a customer isn't a security incident. It's a security incident that ends up in a vendor's training data.

The deeper problem is that these decisions are being made ad hoc, tool by tool, conversation by conversation. That works for a week. It doesn't work as a security program. And customers are already ahead of the frameworks. Security questionnaires now thread AI through the existing categories, how it factors into vulnerability management, how it changes incident response, how you assess it in third-party and supplier risk. That requirement rolls downhill from an auditor, an enterprise customer, or an insurer, and lands on every vendor they use.

The good news is that this is rarely a policy gap. It's an application gap. The controls exist. Your data classification policy already says what can leave the company. Your vendor risk process already governs how you onboard third-party software. Your acceptable use policy already sets expectations for company systems. They just haven't been pointed at this class of tool yet. The right time to have a policy isn't when the questionnaire arrives. It's a few months before.

What's Included

AI Usage Policy

The general case in plain language. Who can use AI tools, which tools are approved, what data can and can't go into them, and how AI agents that connect to your systems are governed. Written so your sales team and developers will actually read it.

AI Coding Agent Governance

A separate policy for a different risk profile. Tier tools by autonomy, from those that only suggest to those that act. Pre-session checklists, file exclusions for secrets, prompt-injection awareness, AI-assisted commit annotation, and dependency validation.

Integration Security Review

Review the security implications of AI features and agents that connect to your data, systems, and code, including AI capabilities that arrived through the side door of an already-approved vendor.

AI Risk Assessment

Identify where AI touches customer data and existing risks, and document how those risks are managed, so the answer is ready when it's asked for in a questionnaire, an audit, or an insurance application.

Vendor Risk for AI Tools

Evaluate AI vendors under your existing vendor risk process. Data handling, retention, subprocessors, training opt-out, and contract terms. Build an approved-tool list on vetted enterprise agreements instead of debating which model is "safe."

Built on Your Existing Controls

Extend your data classification, acceptable use, and secure SDLC controls rather than standing up a parallel program. Smaller scope, faster execution, and less internal resistance.

How Engagements Work

AI governance is scoped at the start, not billed by the month. Together we define which tools are in scope, which parts of your existing security program the governance extends, and what you get at the end. Fixed scope, fixed fee, clear endpoint.

The two most common scopes:

AI Governance Assessment. For companies who know their team is already using AI tools and want a senior read on the exposure. Current-state review, gap analysis against the controls you already have, a risk register, and a prioritized roadmap. Written deliverable.

AI Governance Program Build. For companies who need the artifacts, not just the read. Everything in the assessment, plus the AI usage policy, coding-agent governance rules, the tool and integration review process, and rollout across engineering and the business.

Both produce something you can hand to a customer's security team. Once a program is in place, ongoing governance is available as a light advisory retainer, roughly a day a month for policy reviews, new-tool evaluations, and questionnaire support. That's an option after a build, not the way the work starts.

Who This Is For

Compliance-sensitive software companies whose developers and staff are already using AI tools without formal governance

Companies that process customer PII, financial, or regulated data and can't risk it landing in a vendor's training set

Organizations facing security questionnaires that now ask how AI factors into vendor risk, vulnerability management, and incident response

Teams adopting AI coding agents that can autonomously create files, run commands, and open pull requests

Companies with an existing security program that want to extend it to AI rather than stand up a separate one

Experience & Proof Points

Wrote and deployed an AI usage policy and a separate AI coding agent governance policy for a SOC 2-audited SaaS company, including resolving a conflict between the two.

Applied existing data classification and vendor risk management controls to AI tools rather than standing up a parallel program.

Uses AI coding agents in production engineering work on a live multi-tenant SaaS platform, under the same governance being recommended to clients.

25+ years in technology leadership, including building the information security program this AI governance work extends.

More on the thinking behind this work in AI Governance for Compliance-Sensitive Companies: Where to Start.

Ready to talk?

Tell me what AI tools your team is already using and I'll let you know what a governance engagement could look like.