top of page

AI Governance for Companies That Don't Build AI, They Just Use It

Writer: Shola Hassan
Shola Hassan
Oct 9
2 min read
For most organizations, AI governance starts with the tools they already use. Managing vendor-built AI means treating AI risk as a third-party risk issue—covering data use, privacy, contractual obligations, AI-specific controls, and ongoing monitoring.
For most organizations, AI governance starts with the tools they already use. Managing vendor-built AI means treating AI risk as a third-party risk issue—covering data use, privacy, contractual obligations, AI-specific controls, and ongoing monitoring.

Most of what gets written about AI governance assumes you're the one training or fine-tuning a model. Most organizations I talk to aren't doing that at all. They're using AI features already built into tools they've already bought: a CRM's lead scoring, an HR platform's résumé screening, or a support tool's auto-responses.

That doesn't take you out of scope, and this is the part that catches people off guard. If an AI feature inside a vendor's product produces a biased hiring recommendation or gets a customer-facing decision wrong, the regulatory and reputational exposure lands on the company that used it, not only the company that built it. "We didn't build the model" isn't a governance position; it's just a fact that doesn't change your liability.

What actually useful AI governance looks like for an organization in this position starts with an inventory; every AI feature genuinely in use across the vendor stack, which in my experience is almost always longer than people expect once they go through it tool by tool. It also means vendor due diligence that specifically asks how the AI feature works and what data trains it, rather than leaning on the same security questionnaire boilerplate that was written before half these AI features existed. It means clear, named ownership for each AI feature in use, not a vague assumption that "IT handles that." And it means a process for reassessing when a vendor quietly adds a new AI feature to a tool you're already using, because that changes the risk profile without changing the contract you signed.

I'd frame this as a third-party risk problem wearing an AI-specific layer, because that's what it actually is. If you already have a vendor risk program running, tiering, due diligence questionnaires, and periodic reassessment, most of the structure this needs already exists. What it needs isn't a separate program built from nothing; it's an AI-specific lens added to the one you already have.

The first useful step usually isn't a policy document at all. It's the inventory. Most organizations are genuinely surprised by how many AI features are already live across tools they've had for years, sitting there unexamined because nobody thought to ask.

 
 
 

1 Comment


Shola Hassan
Shola Hassan
Oct 09

A practical way to start: list the five AI-enabled tools your team uses most, such as the AI features inside Microsoft 365, your CRM and your helpdesk. For each, write down who owns it, what data goes in, and what the vendor says it does with that data. That list is your first AI register, and most teams find tools on it nobody had formally approved.

Like
bottom of page