AI Governance

AI Governance for Engineering and Operations

AI is a new vector for existing risks, not a new category. Govern it across engineering and operations without standing up a parallel program.

Start a Conversation

I help companies adopting AI in their product, their engineering, or their operations govern it, especially where customer or regulated data is involved. Usage policies, AI coding agent rules, integration security review, AI vendor risk, and risk assessment, built on the data classification, vendor risk, and acceptable use controls you already have where they exist, and written from scratch where they don't.

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.

Where a security program already exists, this is rarely a policy gap. It's an application gap. 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. Where those policies don't exist, they're short to write, and AI is a reasonable place to start. Either way, the right time to have a policy isn't when the questionnaire arrives. It's a few months before.

Two Tracks

AI shows up in two places, and they need different rules. Most engagements cover both. Some only need one.

AI in Engineering

Coding agents that create files, run commands, and open pull requests. AI assistants inside the IDE. AI features in your own product, and integrations that give a model access to your data or systems. The work here is coding agent governance, AI in the software development lifecycle, and security review of AI integrations before they ship.

AI in Operations

Staff using ChatGPT, Copilot, and similar tools with customer or regulated data. AI features that arrived inside vendor products you already use. New AI vendors nobody vetted. Customer security questionnaires that now ask how you govern AI. The work here is an acceptable use policy for staff, rules for what data can go where, AI vendor risk, and questionnaire answers written before they're asked for.

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

Where you have data classification, acceptable use, and secure SDLC controls, AI governance extends them rather than standing up a parallel program. Where you don't, the engagement writes the minimum set the company needs. 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 existing controls it extends or which ones it needs to establish, 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

Companies adopting AI in their product, their engineering, or their operations, especially where customer or regulated data is involved

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

Companies shipping AI features in their product, or wiring AI into integrations that touch customer data

Staff using ChatGPT, Copilot, or similar tools with customer PII, financial, or regulated data, and no rules for what can go where

Companies whose vendors have added AI features to products already in use, and who need to know what that means for their data

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

Companies with or without a formal security program. If one exists, AI governance extends it. If not, the engagement writes the controls it needs.

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.