Your Employees Are Using AI. Your Risk Register Doesn’t Know.

In 35 years of this work, here’s what we see when mid-market firms open their risk register and we ask about AI: the register usually covers the systems IT manages. Servers, backups, endpoints, access controls. AI is often nowhere on it.

Meanwhile, employees have already adopted a parallel layer of tools. Document extraction in tax or audit workflows. Writing assistants for client correspondence. Meeting transcription. Vendor-embedded “smart” features that arrived in a software update. Marketing tools that retain inputs for model training. Most never went through vendor intake. Many process client financial data, PII, or other regulated information. The register describes one organization; the floor describes another.

The risk register is the document your auditors will examine. If it doesn’t reflect what’s actually happening in your organization, it isn’t a risk management tool. It’s a liability.

The Invisible Technology Layer

AI adoption in mid-market organizations follows a pattern that is fundamentally different from previous technology waves. Enterprise software required procurement approval, IT installation, and budget allocation. Cloud services at least appeared on credit card statements or subscription invoices. AI tools often require none of these. An employee signs up with a personal email, uses a free tier, and integrates it into their workflow within minutes. From the organization’s perspective, nothing happened. From a risk perspective, everything changed.

The pattern is consistent in 2026 assessments: the risk register describes the technology the IT department manages, and employees have adopted an entire parallel layer of AI tools that IT doesn’t know about. That gap—undocumented data exposure through AI tools, AI-generated content with legal or regulatory consequences, and process failures that weren’t anticipated because the AI dependency wasn’t documented—is where the incidents will come from.

The Visibility Problem

AI tools often leave no footprint on managed endpoints. They run in browser tabs, operate through vendor integrations, and authenticate with personal credentials. Traditional IT asset management doesn’t see them.

The Classification Problem

Employees don’t think of many AI tools as “AI.” A document extraction feature embedded in their tax software, an AI-powered search in their email client, a smart template in their CRM—these don’t register as AI adoption in the employee’s mental model.

The Data Flow Problem

Every AI tool that processes client data creates an undocumented data flow. Where does the input go? Does the vendor retain it? Is it used for model training? These questions have regulatory answers that most organizations haven’t asked.

What the Auditors Will Ask

When a firm is pursuing SOC 2 Type II, auditors increasingly treat AI as in-scope whenever a tool processes data relevant to the trust services criteria. If an AI tool touches in-scope data, the tool’s risks are in scope for the assessment—whether or not the organization documented it. Waiting for a named AICPA FAQ is not a strategy; map the tools and the data flows now.

For organizations subject to other frameworks, the exposure is parallel. HIPAA-covered entities must account for all systems that process PHI, including AI tools employees adopted without authorization. PCI DSS requires an inventory of all systems that store, process, or transmit cardholder data—including AI-powered analytics tools that a marketing team may have connected to payment data. NYDFS 23 NYCRR 500 requires a current asset inventory and risk assessment that covers all information systems. An AI tool processing nonpublic personal information is an information system.

AI Tools We Commonly Find Undocumented

Meeting transcription: Records and transcribes client meetings. Audio and transcripts stored on vendor servers. Client names, financial details, strategic discussions all captured. No DPA in place.

Document extraction: Reads uploaded documents (tax returns, financial statements, medical records) and extracts structured data. Document content transmitted to vendor for processing. Retention policy unknown.

Email drafting assistants: Generates and edits client correspondence. Reads the email thread for context. Client communications, including sensitive details, used as model input.

Vendor-embedded AI: Features within existing software that use AI to enhance functionality—smart search, automated categorization, predictive analytics. Often enabled by default in software updates without explicit user adoption.

AI coding/automation tools: Used by IT staff or power users to automate workflows. May process data from multiple systems, creating undocumented integration points.

From Invisible to Governed: A Practical Path

The path that works for mid-market organizations facing this gap is the same one we use in practice: discover, classify, decide, document. A focused four-week sprint is enough to go from “AI isn’t on the register” to “we know what we use and how we govern it”—without inventing a theater of specific outcomes.

Week 1: Discovery. Run a three-pronged discovery process. First, a technical scan: DNS logs and web proxy data for connections to known AI provider domains (OpenAI, Anthropic, Google AI, Microsoft Copilot, and the other common services). Second, a department-by-department walkthrough with managers, asking not “do you use AI?” but “walk me through how you process a typical client engagement from intake to deliverable.” The AI tools surface in the workflow description even when people don’t think of them as AI. Third, a vendor inventory review: examine every SaaS subscription and check release notes for AI features added in the last twelve months.

Week 2: Classification. For each discovered tool, document: what data it processes, where that data goes, whether the vendor retains inputs, whether the tool is used in a client-facing or decision-making capacity, and what the vendor’s data handling terms say. Tier the tools by risk: Tier 1 (processes client PII or regulated data), Tier 2 (processes internal business data), Tier 3 (no sensitive data). Tier 1 tools get immediate attention. Tier 3 tools get documented and monitored.

Week 3: Decision. For each Tier 1 tool: approve with controls, replace with an approved alternative, or prohibit. Leadership should decide based on written risk assessments—not blanket prohibition, but risk-informed governance. In practice we often see some tools approved after a DPA and retention limits, some replaced with a firm-provisioned alternative, and transcription or training-on-inputs tools prohibited when client meeting content is in play.

Week 4: Documentation. Update the risk register to include every discovered AI tool. Add AI governance controls to the information security policy. Create a lightweight AI tool intake process (a one-page request form with a short turnaround) so employees have a path to request new tools without bypassing governance. Brief all staff on the new expectations.

The 30-Day AI Governance Sprint

Week 1: Discover all AI tools via DNS analysis, manager walkthroughs, and vendor inventory review
Week 2: Classify each tool by data sensitivity tier and document data flows
Week 3: Risk-based decisions for each Tier 1 tool: approve with controls, replace, or prohibit
Week 4: Update risk register, policies, and intake process. Brief all staff.
Ongoing: Quarterly re-discovery scan. Annual policy review. Intake process for new tools.

The Competitive Advantage of Getting This Right

In proposal and vendor-due-diligence work, we increasingly see buyers ask whether AI tools are inventoried, whether data flows are documented, and whether governance exists. Firms that cannot answer lose time—or the deal—to firms that can. That is not a compliance story; it is a market story.

AI governance is not purely defensive. Clients, prospects, and regulators are beginning to differentiate between organizations that govern their AI use and those that don’t. A current AI inventory, documented data flows, and a functioning intake process are becoming competitive qualifiers—not just checkboxes.

The tools themselves are often worth keeping. The problem we see is not “employees use AI.” It is that no one evaluated the tools, documented them, or set the controls needed to use them responsibly. A short, honest sprint—discover, classify, decide, document—turns “AI isn’t on the register” into “we use AI deliberately, with documented governance, and we can prove it.” That transformation is available to any organization willing to look at what’s already happening inside its walls.

References

Infosecurity Magazine. (2026, March 23). Most Cybersecurity Staff Don’t Know How Fast They Could Stop a Cyber-Attack on AI Systems.

Note: A prior draft cited a Gartner “half of incident response by 2028” line and “AICPA 2025 guidance on AI in SOC engagements.” Those claims were removed because they could not be verified as exact matches to primary sources (Gartner’s March 17, 2026 press release addresses custom-built AI-driven applications specifically; AICPA TQA Section 9561 on AI in SOC examinations was published September 11, 2026, not as 2025 guidance).