AI governance is not a new program. It is your existing security, vendor, and compliance work, extended to cover the AI tools your people already use.
Most of the organizations I work with are not building AI. They are buying it. A law firm adopts an AI drafting assistant. A clinic signs up for ambient scribing. A bank turns on the AI features its core platform just shipped. A manufacturer uses AI to flag maintenance issues on the production line.
The model belongs to the vendor. The decisions about access, data, oversight, and acceptable use still belong to you. In my view, that is where most AI risk lives in the mid-market, and it is where a vCISO earns their keep.
Pick the framework for the job, not the other way around
The NIST AI Risk Management Framework is voluntary guidance built on four functions: Govern, Map, Measure, and Manage. Its Generative AI Profile adds guidance for generative AI risks. ISO/IEC 42001 sets requirements for an AI management system you can be certified against. SOC 2 is an independent CPA examination of controls within a defined scope. It is not an AI certification.
These work together. They are not interchangeable. Before I recommend any of them, I ask one question: what are you trying to prove, and to whom? Managing AI use across the workforce, answering customer due diligence, clearing a vendor review, preparing for an audit, and pursuing ISO/IEC 42001 certification are different goals. Each one sets a different scope and calls for different evidence.
Find the AI your people are already using
An inventory built from approved purchases will miss most of it. Employees paste work into public tools. Vendors you approved years ago quietly ship AI features nobody reviewed.
Interviews with department leaders are a start, not the finish. I back them up with evidence: SSO and OAuth grants, expense reports, browser extensions, and DNS or proxy logs for AI service domains. Do this within company policy and with appropriate employee notice. Discovery tells you where AI is in use. It does not tell you what data was submitted or how the service was used. The assessment below answers that.
For each AI tool or feature, record:
- Business purpose and accountable owner
- Users, and whether it is internal or customer facing
- Data it receives, retrieves, or generates
- Provider, model, integrations, and other dependencies
- Human review and approval steps
- Existing safeguards, open risks, and planned actions
The inventory is a living record. Give it an owner. Trigger a review when a new tool is proposed, a vendor changes its service, or an existing use expands.
Data obligations come first
The first question is rarely "which AI framework should we use?" It is "what information can go into this tool, and are we allowed to use it this way?"
Law firms. Client confidentiality, engagement terms, and professional duties apply before anyone uploads a matter file or a draft brief to an AI vendor.
Healthcare. If ePHI is involved, the HIPAA Security Rule applies. That means reasonable and appropriate safeguards, a business associate agreement where required, and access controls that hold up.
Financial services. Start with the laws, regulations, and supervisory expectations that apply to your institution. For institutions under FTC jurisdiction, the GLBA Safeguards Rule covers customer information, including oversight of service providers.
Manufacturing. Trade secrets, product designs, and production data are the exposure. They leave the building just as easily as client files do.
Across every sector, check contracts, state laws, records retention, intellectual property, and customer commitments. I coordinate the security and risk review. Legal, privacy, compliance, and clinical leads interpret the obligations in their own lanes.
Match the review to the risk
A writing assistant used on public information does not need the same review as a tool that reads client files, summarizes patient visits, or informs a credit decision. Treating them the same wastes time on the first and shortchanges the second.
The questions I ask for each use case:
- Data exposure: Will it touch personal, confidential, regulated, or customer information?
- Vendor handling: What does the contract say about retention, model training, subprocessors, data location, breach notice, and deletion?
- Access and security: Who can use it, what can it reach, and is activity logged?
- Output reliability: What happens when the output is wrong, incomplete, or misleading?
- Human oversight: Who reviews consequential outputs, and can they reject them?
- Business impact: Who gets hurt by an error, and how badly?
- Change risk: What happens when the vendor changes the model, features, or terms?
Keep tiering simple. Lower risk uses get an approved tool and clear data rules. Higher risk uses get a documented assessment, vendor review, testing, a named approver, monitoring, and a response plan. Approval belongs to the use case, not the tool. When the data, integrations, or decision authority change, the assessment gets another look. That matters most for AI agents, which take actions instead of just producing text.
Reuse your controls, then close the AI gaps
I review what already exists before I write anything new. Vendor management, access reviews, training, change management, incident response, and risk assessments are usually a solid foundation. Building a parallel AI program on top of them doubles the work and splits the evidence.
The gaps I typically close:
- Add AI tools, vendors, and AI agents to inventories and access reviews.
- Define which data employees may enter into approved tools.
- Require an owner and documented purpose for each significant AI use.
- Add AI questions to vendor reviews and risk assessments.
- Set approval and testing requirements for higher risk uses.
- Add AI events to incident response, including data exposure and harmful outputs.
- Record significant changes to tools, model settings, integrations, and data sources.
- Train employees on approved uses, prohibited data, and how to report concerns.
Reusing controls does not mean they already cover AI. You still need evidence that each control fits the actual systems, data, and use.
Put AI into vendor review
Most AI arrives through a vendor. "Do they have a SOC 2 report?" is not enough of a question anymore.
Review the contract and vendor documentation for data use, retention, model training, subprocessors, security controls, breach notification, deletion, and material service changes. Then check whether the AI feature is actually inside the scope of their assurance report. Often it is not. Record the open questions and who accepted the remaining risk.
A law firm evaluating a drafting assistant needs to know whether client material can be submitted, whether it is retained or used for training, who can access it, and whether client agreements allow the use. Then set an approved workflow and define when attorney review is required before anything is shared or filed.
A clinic buying ambient scribing needs to know what gets captured, how recordings and transcripts are handled, who can access them, and what the vendor is responsible for. The clinician owns the final note. Test the workflow and set a process for correcting errors.
Watch the proposed SOC 2 changes, but don't overreact
In October 2026, the AICPA issued an exposure draft of proposed 2027 SOC 2 Trust Services Criteria with expanded considerations for emerging technologies, including AI. Public comments close January 15, 2027. If approved, the criteria apply to engagements beginning on or after December 31, 2027, with early adoption permitted.
Until then, it is a proposal. Talk to your CPA firm about which criteria apply to your current engagement. My advice: build a control map that is easy to update when the final version lands, and do not sell proposed language to customers as a current requirement.
A sample 90 day plan
| Period | Activities | Deliverables |
|---|---|---|
| Days 1 to 30 | Align leadership, identify stakeholders, inventory AI use, review policies and obligations | Scope statement, AI inventory, governance roles, initial risk register |
| Days 31 to 60 | Prioritize use cases, assess higher risk tools, review vendors, map existing controls, identify gaps | Risk assessments, vendor review updates, control map, remediation plan |
| Days 61 to 90 | Implement review and approval workflows, close priority gaps, organize evidence, brief leadership | AI use policy, approval workflow, incident response updates, evidence index, leadership readout |
This is a planning example. The real timeline depends on your size, the number of tools, and how sensitive the data and decisions are.
Measure progress without overclaiming
Track what shows the program is real: AI tools inventoried, percentage with assigned owners, higher risk uses assessed, priority remediation completed, vendors reviewed, and employees trained.
Be precise about assurance claims. Using NIST AI RMF does not make you "NIST certified." A readiness assessment is not ISO/IEC 42001 certification, which comes from an independent certification body, not ISO itself. SOC 2 is a report from an independent CPA examination, not a certification. Overclaiming in a customer questionnaire creates a problem you did not have before.
Make governance usable
Good AI governance is boring in the right way. People know which tools are approved, what data stays out, who owns each use, and how to raise a concern. Leadership sees the risks that remain and decides on them.
The goal is a process employees follow and leaders oversee, not a stack of policies nobody reads.
When something goes wrong, the same accountability applies. Read: AI Can Accelerate the Attack. Your Response Still Needs a Human Decision.
If you are rolling out AI tools or want an honest read on your current program, contact Antares to scope an AI risk and control assessment.
