Key Takeaways
- AI due diligence has moved from novelty to standard. Questionnaires now ask which models you use, what data reaches them, whether customer data trains anything, and who reviews AI-assisted decisions.
- Most companies can't answer, not because they're careless, but because nobody owns the inventory. AI arrives through features, SaaS updates, and individual employees — rarely through a procurement gate.
- You do not need a new framework to start. Vendor management, data classification, access control, and change management already cover most of the ground.
- ISO/IEC 42001 and the NIST AI RMF give you structure when you need it. Start with an inventory and a use policy; formalize when a customer, a regulator, or your own risk appetite requires it.
The question that stops the deal
A security questionnaire lands from a prospect. Somewhere past the encryption section, past the incident response section, there's a block that didn't exist two years ago:
Do you use AI or machine learning in the delivery of your service? List all models and providers. Is customer data transmitted to any third-party AI service? Is customer data used to train any model? Describe your process for human review of AI-generated output. Do you maintain an inventory of AI systems?
Six questions. And for a lot of companies, the honest answer to the first one is "almost certainly yes, and we'd need a week to find out where."
That's not negligence. It's the shape of how AI actually entered the business.
AI didn't come through the front door
Traditional vendor risk assumes a decision: someone evaluates a tool, it goes through review, it gets approved, it lands in the inventory. AI mostly skipped that path.
It arrived inside tools you already bought. Your support desk shipped an AI summarizer. Your CRM added an assistant. Your code host turned on a copilot. Nobody made a procurement decision — a feature flag flipped and a new data flow opened.
It arrived through individual employees. Someone pastes a customer support transcript into a chatbot to draft a reply. Someone runs a contract through a summarizer. Someone uses a transcription tool in a client call. Every one of those is a data transfer to a third party, and none of them generated a ticket.
It arrived inside your own product. A feature that "uses AI" is a subprocessor relationship, a data flow, and — depending on what the output does — a decision your customers may need explained.
The result is a gap that gets exposed by a questionnaire rather than by an incident: real AI usage, no record of it.
Start with the four questions you'll be asked
Before frameworks, before policies, get to the point where you can answer these accurately.
1. Where is AI in use? Product features, internal tooling, vendor-embedded capabilities, and employee-adopted tools. Include the ones nobody approved — especially those.
2. What data reaches it? For each use, what classification of data is involved? Public marketing copy and customer PHI are the same "AI usage" on a questionnaire and radically different risks. This is where an existing data classification scheme earns its keep.
3. What are the provider's terms? Does the vendor train on your inputs? What's the retention period? Is there a zero-retention or enterprise tier, and are you on it? These answers are in the contract or the API terms, and they change more often than you'd like.
4. What happens to the output? This is the one most teams underweight. AI that drafts an internal summary is low stakes. AI that scores an applicant, flags a transaction, prioritizes a clinical queue, or auto-responds to a customer is making or shaping a decision — and that needs a documented human review step, an escalation path, and a record of when the model was wrong.
Four answers, maintained honestly, will get you through the large majority of AI due diligence you'll face in the next year.
Shadow AI is the real exposure
Ask any security team where their AI risk sits and most will say "our product features." In practice, the sharper edge is employee usage nobody logged.
The failure isn't dramatic. It's a support engineer pasting a log file with customer identifiers into a free chatbot to debug faster. It's a sales rep running a signed customer contract through a summarizer. Individually reasonable, cumulatively a set of undisclosed data transfers to processors that never appeared in a DPA — which is a contractual problem and, under several privacy regimes, a regulatory one.
The workable response is not a ban. Bans push usage to personal devices where you lose all visibility. What works:
- A short, specific acceptable-use policy — not "use AI responsibly," but explicit lists: never paste customer data, credentials, or unreleased material into non-approved tools; here are the approved tools; here's how to get one approved.
- A fast approval path. If getting a tool reviewed takes six weeks, people route around it. A lightweight intake that resolves in days is a security control, not a convenience.
- A real acknowledgement record. The policy only counts as a control if you can show who read it and when — and that's operating evidence, not a document in a folder.
Where the frameworks fit
Two references matter, and neither needs to be your starting point.
ISO/IEC 42001 is the AI management system standard — the AI analogue to ISO 27001. Scope, roles, risk assessment, impact assessment, lifecycle controls, continuous improvement. Its main value is that it's certifiable, which makes it the thing enterprise buyers will eventually put in a contract. If you sell AI-centric software upmarket, this is where the conversation lands.
The NIST AI Risk Management Framework is voluntary, non-certifiable, and organized around four functions: govern, map, measure, manage. It's better as a thinking tool than a checklist, and it's a reasonable way to structure your first AI risk assessment without committing to certification.
The practical sequence: inventory first, use policy second, risk assessment on the highest-impact uses third, formal framework when a customer or regulator makes it necessary. Reversing that order — starting with the standard — produces an impressive management system describing AI usage nobody has actually mapped.
Most of the controls already exist
The reassuring part: AI governance is less greenfield than it sounds. Map it onto what you have.
- Vendor management already handles third-party risk. AI providers are vendors. Tier them, collect their SOC 2 or ISO reports, track their subprocessors, and re-review when terms change — which, with AI providers, is often.
- Data classification already tells you what's sensitive. The new rule is simply which classifications may cross which AI boundary.
- Access control already governs who can reach what. Extend it to model endpoints, API keys, and admin consoles.
- Change management already governs production changes. A model version bump, a prompt change, or a new provider is a production change with a distinct failure mode: it can degrade quietly without throwing a single error.
- Incident response already exists. Add the AI-specific scenarios — sensitive data disclosed to a provider, a materially wrong output that reached a customer, a provider breach — and make sure someone knows who to call.
What's genuinely new is narrow: AI-specific impact assessment, human-oversight design for consequential decisions, and monitoring for output quality drift over time. That's an extension of your program, not a parallel one.
A ninety-day starting point
Days 1–30 — See it. Build the inventory. Ask every team what they use, check SaaS admin consoles for newly enabled AI features, review your own product for AI-backed functionality, and pull the provider terms for each. Expect the list to be longer than anyone predicted.
Days 31–60 — Bound it. Publish the acceptable-use policy, tracked with real acknowledgements. Route AI vendors through the existing vendor process. Classify each use by data sensitivity and decision impact, and put oversight on anything consequential.
Days 61–90 — Prove it. Write the questionnaire answers down before someone asks. Run a risk assessment on your top few uses. Decide — deliberately, in writing — whether ISO 42001 is on your roadmap or explicitly deferred. Both are defensible; having never considered it is not.
The takeaway
AI governance is following the exact arc security compliance followed a decade ago: informal, then customer-demanded, then contractual, then table stakes. The companies that had an inventory and a use policy early spent the transition answering questions. The ones that didn't spent it building programs under deadline pressure, in the middle of a deal cycle.
You almost certainly have more AI in your environment than your documentation reflects. Finding out how much is a week of work. Explaining it to a prospect on a Thursday afternoon, with no inventory, is considerably more expensive.