I spent the first chapter of my career drinking from a literal firehose. As an analyst in the Canadian Armed Forces (CAF) during the peak of the Afghan war years, I often got thrown into a job or task and then formally trained up on it later. Operational needs always came first; they still do today. My job, crudely put, was to separate signal from noise and never blow the sources and methods that made the collection possible. Two decades later, I've gone from being an entry level SOC analyst at a MSSP to CISO at a global commercial enterprise with millions of active users. The only thing that's really changed is the gauge of the pipe and the speed at which your newest analyst will wire it directly into their coffee cup if you don't give them a better alternative.
Enterprise AI governance isn't new. It's a sources-and-methods problem wearing a different uniform.
I'm writing this for the working CISO/CIO/CTO, the founder, and the board director currently staring at a 60-slide vendor deck trying to figure out how much of it is real. I don't have a STEM degree. I studied Political Science & Psychology at a military college, in case you were wondering. If you're reading this, you're probably more formally educated and qualified than me, if we're being honest. I saying this because I am coming at this from a humble place. My intent is that I care about helping people get this right, and sharing knowledge is how we do that. Most of what I know I picked up from things getting broken in prod, inheriting other people's incidents, and getting chewed out by superiors or—even worse—auditors who were, annoyingly, right. What follows is a six-month plan to a defensible V1.0, at large enterprise scale and at 30-person-startup scale, because the principles don't change when the budget does.
One rule before we start...
If your AI governance program is built on nice slides, third-party opinions, and zero internal friction, you don't have a program. You have a hallucination. The best security work I've ever seen came from people who'd personally lived through the scenario they were designing for. Everything else is theatre.
Why most of these programs collapse
I've reviewed, audited, competed against, and in a few cases cleaned up after a lot of governance programs over the last decade. The ones that fall apart all fail the same way. Somebody downloads a policy template from a standards body, runs a tabletop without a single technical operator in the room, declares victory at "we have a policy," and goes home. Then a product team quietly spins up a shadow Copilot tenant. Marketing pastes a customer list into ChatGPT to get campaign copy. An engineer wires an open source MCP server straight into production because it was easy. And the CISO finds out on a Tuesday morning in a Slack DM that opens with "hey so this might be bad."
The second failure mode is worse. I call it admiring the beauty of your own ideas. You build a framework, skip external red teaming, skip third-party audit, and tell your board you're covered. You're not. You're self-certified. Those aren't the same word. The hardest part of this job isn't writing the policy. It's being honest about what your policy actually prevents versus what it just documents.
The shops that get this right start from the same uncomfortable premise. Everything is denied until it's reviewed, registered, and owned by a human with a name. Every approved path has a kill switch somebody has actually tested, not drawn on a whiteboard. Every output is logged in a way a forensic investigator would respect, not a marketing lead. My gut test: if my board asked tomorrow what Gemini did for Sarah in Finance last Tuesday at 14:00 UTC, could I answer without calling a vendor? If no, we haven't landed yet.
Here's the plan.
Months 1 and 2: Governance and Policy
You can't secure what you haven't named, so first sixty days are about getting your arms around what's actually happening inside your four walls, deciding what gets through the door going forward, and building a default posture that doesn't leak.
Deny by default is the single most important posture decision you'll make, and it's the one that gets the most pushback. Product leaders will tell you it kills innovation. It doesn't. It forces innovation to have an owner. Without a default-deny, your AI footprint is whatever your people felt like signing up for on a free trial last quarter, and it's bigger than you think. Run a DLP or SWG query against the top hundred AI domains. One of my peers found an entire customer service team had been routing tickets through an unapproved consumer chatbot for eight months. Nobody was malicious. Nobody asked.
The guts of governance should live in three registries:
-
Solution Registry serving as your list of every AI model, service, and provider reviewed and approved, with named owners and risk classifications.
-
Tooling Registry covering every MCP server, skill, plug-in, and integration that's been vetted.
-
Data Registry telling you every internal knowledge source AI is allowed to read, each one having passed a STRIDE threat model and a real backup and recovery check before the model gets near it. That last one is where most organizations cut corners and where they get bit. If a data source doesn't have a tested restore path, AI doesn't connect to it. That's a line I don't move.
Risk classification turns governance from a shelf document into something useful. You can use something as simple as five tiers. R0 is pure internal productivity, no sensitive data, no user impact. R1 touches real workflows but doesn't decide anything user-facing. R2 is user-visible but reversible. R3 is user decisioning. R4 is identity, safety, legal, or irreversible. In other words, it's the tier where you can't afford to be cute. Your approval workflow runs in two lanes. Fast lane for R0 and R1 on pre-approved infrastructure, no new vendors, no write access, no confidential data, one to two weeks end to end. Slow lane for everything else, two to six weeks, full stakeholder review. If the slow lane gets bypassed for the CEO's pet project, you don't have a lane system, you have a suggestion box.
At large enterprise scale this lives inside ServiceNow or a Jira-plus-Confluence stack with workflow automation, a formal AI governance committee chaired by your CIO or CISO with quarterly Senior Leadership attestation, and probably two or three dedicated headcount split between Architecture and InfoSec. The HLD template has a mandatory AI declaration section that can't be skipped. Your architects will complain. Good. At SME scale none of that is realistic and you don't need it. A single shared spreadsheet with four tabs, a one-page policy your CEO actually signs, a monthly thirty-minute touchpoint with your senior engineer, product lead, and whoever runs IT, and a risk table that fits on a whiteboard. What you really need is one person empowered to say no and a CEO who will back them. The framework is easy. The backing is hard.
Either way, you need a written AI Governance Policy. Not an HLD. A policy. It covers what's approved and what isn't, what data can and can't go into a prompt, whether personal accounts are allowed (Pro Tip: they aren't), what human review is required, and a real enforcement path your HR team has blessed. A policy without HR teeth is a poster you put up for auditors.
Months 2 and 3: Data Security and Privacy
Here's where the real exposure lives, and it isn't the AI. It's the people pointed at it. Models don't accidentally leak data. People using models leak data. Retrieval pipelines pointed at poorly classified stores leak data. Vendors who didn't opt you out of training leak your data in ways you won't find out about until someone else's chatbot quotes your internal memo back at them. Make the leak physically difficult, culturally awkward, and technically auditable, in roughly that order.
The one rule I'll die on: no PII, no credentials, no API keys, no customer records, no strategic business information goes into a prompt unless that specific use case has been explicitly approved, the data is properly contracted for, and the model vendor has opted you out of training on your traffic in writing. If your vendor won't opt you out, they don't get your work. Full stop. I've walked away from demos with very smart vendors over this exact clause. Not negotiable, and honestly it's the single most effective control you'll put in place. Everything else is hygiene.
On the application side, input and output sanitization is the app's job, not the model's. The minute you trust the model to police its own output, you've lost the plot. The application fetches the data, decides what to pass in, and validates what comes back. The model is a clever parameter in between.
Provenance is the thing nobody wants to talk about until a regulator shows up. If AI is producing content that reaches a customer, makes a decision, or sits in your records for audit, you need to know which model made it, on what input, under which guardrail, when, and whether a human reviewed it. Prompt, response, model version, reviewer name, timestamp, confidence score if the model gives you one. That log has to survive a regulator, a plaintiff, and a breach investigator at the same time, because in my experience they show up as a package.
At large enterprise scale: a full DLP stack inspecting traffic to known AI endpoints, a data classification schema that actually propagates through bucket policies, column tags, and IAM roles, a clean room capability for vendor model interaction with regulated data, embedded cryptographic provenance on anything sensitive you generate, and a named data protection officer sitting in the AI approval flow. If you've got the scale, doing less is negligence.
At SME scale: a commodity secure web gateway with domain-level AI blocking turned on for anything not on your list, a one-page data input rulebook you can laminate and hand to every new hire, everybody onto company SSO, every public chatbot UI blocked at the browser. I've seen a startup do this for under fifteen hundred a month all-in and be genuinely defensible. The trick wasn't the tools. It was the founder who wouldn't grant exceptions.
A word on regulation, because everybody wants to ignore it until Q4. PIPEDA, GDPR, the EU AI Act, the Training Data Bill of Materials (TDBOM) framework I've been advocating for in Canadian federal procurement. They're all converging on one demand. Prove where your data came from. Prove where it went. Prove you had the right to use it. Start capturing that lineage now even if nobody's asked yet, because they will, and retrofitting provenance after the fact is a special kind of hell.
Months 3 and 4: Infrastructure and Secure Deployment
Here's the unpopular opinion I keep getting asked about on podcasts. Until somebody builds a large language model that can safely talk to the open internet without leaking, getting jailbroken, or quietly wandering off with your data, treat every AI deployment as if it will do all three. That doesn't mean don't deploy. It means deploy inside a blast radius you can actually contain.
Three architectural commitments make the rest of the program tractable.
First, enterprise-hosted services, company credentials, SSO, nothing else. A good example of this is if your shop uses AWS Bedrock with Google Gemini at the workspace tier and a code assistant under Bedrock for engineering. Anthropic's Claude and GitHub Copilot can be approved for use inside Bedrock for specific use cases with documented risk tables. Everything else gets an HLD or it doesn't run. Personal accounts are banned as policy and backed by technical controls. If a developer can't get an API key from IT, they don't get an API key. They'll complain. They complain about SSO too. They'll live.
Second, the principle I'll defend against anyone trying to sell me an agentic future: AI is a function call. In every end-user-facing app, AI takes controlled input and returns controlled output. Your code decides what to do with that output. AI doesn't query your databases. AI doesn't execute actions. AI doesn't spawn sub-agents that go find things to do on their own time. AI returns a risk score, a classification, or a string of text. Your code suspends the account, flags the transaction, renders the copy. This principle eats roughly eighty percent of the agentic attack surface and costs you nothing except some developer ego.
Third, parameterized writes only. Same principle we've used since 1999 to stop SQL injection. Hardcoded query, AI output dropped into a parameter slot, permitted types limited to strings, booleans, or an enum drawn from a fixed set you defined in advance. AI does not construct API calls. AI does not emit raw SQL. If a vendor is selling you an agent that can autonomously modify production state, send them my number, I'd love that conversation.
Kill switches are the thing most programs lie about, so every approved AI path needs a documented, tested kill switch a named owner can pull inside fifteen minutes. SSO group removal, tooling registry flag flip, feature flag, model disable at the Bedrock level, data rollback where it applies. If nobody's pulled the switch in a drill, the switch is imaginary. I had one at a previous shop that looked great on paper and failed the first time we ran it because the on-call rotation had shifted and nobody remembered the runbook. We fixed it, then drilled it every quarter.
Large enterprise translation: a centrally managed MCP gateway, BYOK or HSM integration on anything touching regulated data, isolated compute tenancies for the really sensitive workloads, configuration drift detection running continuously, and a standing red team with a specific remit to go break your AI stack. You'll spend real money on this and it's worth every dollar if you have the exposure.
The SME approach is almost defiantly simple (and, therefore, much easier to execute). Use the hyperscaler managed services. Don't self-host models unless you have a very specific reason and the talent to match. Flat allowlist of approved AI domains at your SWG. One feature flag per AI path that somebody on DevOps can flip from their phone. One annual external pen test scoped to include AI. If the pen test vendor can't tell you off the top of their head what indirect prompt injection is or how retrieval poisoning works, get a different vendor. I mean that.
Months 4 and 5: Monitoring and Operational Resilience
This is the stage where I can tell within five minutes whether a CISO is actually running a program or just managing optics. Monitoring is where governance meets reality, and most organizations treat it as a box they ticked at go-live and haven't looked at since. Then the breach notification lands and everyone's shocked.
Your audit logs have to be real! Every AI invocation produces an entry with model ID, input, output, user, app context, timestamp, guardrail evaluations, and any write it triggered downstream. Centralized, retained against your longest regulatory clock, accessible to an investigator inside an hour, not a week. If your vendor doesn't expose the raw telemetry, pick a different vendor. I've killed procurement processes over this. Zero regrets.
Adversarial testing has to be scheduled, not one-off. Prompt injection, retrieval poisoning, jailbreak attempts, context overflow, output filter bypass. Models update. Prompts drift. Your guardrails age like produce, not wine. If you're not paying for external testing, black box and gray box evaluation against your AI surfaces, you're flying blind, and grading your own homework doesn't count as passing the class. Your SOC runbooks also need AI scenarios in them. Model compromise. Training data exfiltration. Vendor breach involving your data. A successful prompt injection that reached production and did something. These aren't the same patterns as ransomware, and your analysts need to have walked through them in a tabletop before the real one hits. The first tabletop I ran on this was humbling. That's the point.
Data drift monitoring closes the loop. Model outputs degrade silently. A classifier that was ninety-four percent accurate in August can be seventy-two in February because the world shifted and nobody changed a line of code. Define the metric, pick the threshold, wire the alert. This is where product engineering and security have to actually work together instead of lobbing Jira tickets at each other.
For a large enterprise, this is dedicated AI SOC coverage tied into your managed security provider, SIEM rules purpose-built for AI telemetry, quarterly adversarial exercises, drift monitoring owned by a product manager with teeth, a crisis comms runbook for AI disclosure events, and SLT tabletops twice a year at minimum.
SMEs are dramatically simpler and I'd argue more defensible because of it. Forward your vendor audit logs into whatever SIEM or log aggregator you already have. Write five AI-specific detection rules. Run one external AI-focused red team engagement a year, even a small one. Book a ninety-minute tabletop annually where your engineering lead, your legal advisor, and your CEO walk through a mock AI incident. That's the bar. Most companies, at any size, aren't meeting it.
Months 5 and 6: Talent and Culture
I'll say this bluntly because I've said it on record before: The technical skills are the easiest part of this job. Those you can hire for. What's hard is building a team where people will say no to the CEO when the CEO is wrong, where a junior analyst is comfortable escalating a bad AI output to a principal engineer without getting their head bitten off, where everybody understands that shipping fast is nothing compared to shipping right, and that we can always re-ship.
Hire operators over theorists, every time. The best AI security people I've worked with were SOC analysts first, or pen testers first, or platform engineers first, or occasionally intelligence operators who grok the sources-and-methods problem at a cellular level because they've lived it. Book knowledge is useful. Scar tissue is irreplaceable, and you can't fake it. I can tell inside five minutes of a technical conversation whether someone's done the thing or read about it. Most of us can.
Train everyone, not just the nerds. Every employee is an AI attack surface because every employee can paste a customer record into a public chatbot without thinking. I'm partial to the policy assistant approach, where staff can ask a governed internal AI tool what's approved and get a real answer. Short and frequent beats long and annual. Nobody remembers the thirty-minute mandatory compliance video. They do remember the Tuesday five-minute refresher that said "don't paste PII into Gemini, here's why."
Human-in-the-loop has to be a cultural default, not a checkbox. PR reviews stay mandatory. AI-generated legal goes through Legal. AI-drafted marketing copy goes through Marketing review. AI code follows the exact same bar as human code, and if it doesn't compile, doesn't lint, doesn't pass tests, it doesn't merge. I don't care that an AI wrote it. Your name is still on the commit.
Promote the people who protect the company. This is where culture lives or dies. If your organization rewards the person who cut corners to ship over the person who held the line on data governance, your program erodes inside a year no matter how good the documents look. I've watched good CISOs leave because the culture quietly told them their caution was unwelcome. The first meeting where somebody important gets told no is where your culture gets set. Make sure that meeting goes well.
Large enterprises need a role-based training matrix, an AI Ethics Committee with representation from outside security, dedicated learning paths, a named AI security lead, and biannual tabletops that include the board risk committee. SMEs can acceptably work with a monthly lunch and learn, a written AI best-practices guide short enough to read, one AI champion on the engineering team with real authority and air cover, and a crystal clear CEO statement that the rules apply to everybody, founders included. That's the whole play at small scale, and it outperforms a lot of the big-enterprise programs I've seen.
What V1.0 actually means
V1.0 isn't perfection, it's just a start. Anyone promising you perfection is selling you something. V1.0 is a defensible starting line. At the end of six months, if your board asks what AI is running in your enterprise, under what controls, touching what data, reviewed by whom, with what kill switch, you should be able to answer in a single meeting without calling a vendor. That's the bar. Everything past that is V1.1 onward, and you'll iterate every quarter for the rest of your career, because the tech will.
My biggest applicable professional lesson for this all from my army days was that intelligence operators work by disciplines that don't change regardless of the collection platform. You validate the sterile environment before you collect. You protect the sources and methods. You never forget that some actions are irreversible once taken. Those map directly onto what we're doing with AI right now. Your sterile environment is your data classification and your approved ecosystem. Your sources and methods are the proprietary data, prompts, and fine tuning that give your AI its edge over whoever's trying to knock you off. Your irreversibility is what happens when an autonomous agent makes a write your audit log can't reconstruct. The muscle memory I built in a uniform turns out to be exactly the muscle memory this moment is asking for, which I find darkly funny and quietly reassuring.
Two last things...
You don't need every shiny AI tool that launches on a Tuesday even if it promises the exact miracle that you somehow need in that very moment. You need the ones that serve your business and can be governed. Vendors push you toward complexity because complexity sells seats. Push back. Simpler architecture is more defensible architecture, and more defensible architecture sleeps better at night.
Respect operators over vendors. I'll listen all day to an engineer who's actually shipped what they're telling me about. I'll listen politely, for a much shorter window, to an analyst who read a Gartner report. If you're a CISO/CIO/CTO or a founder reading this, build your circle out of operators. They'll tell you the truth even when it's inconvenient, which it usually is.
If you disagree with any of this, come find me. I'll probably still be wrong about something, and I'd rather hear it from you now than from my auditors next cycle.
This article appeared originally on LinkedIn here.
