A Cybersecurity Awareness Month series from Thompson Coburn’s Data Governance, Privacy and Cybersecurity practice group
The AI Risks Worth Watching Are Mostly Old Ones
October is Cybersecurity Awareness Month. This year, Thompson Coburn’s Data Governance, Privacy and Cybersecurity practice group is focusing on a foundational question for any organization adopting AI: does it know its data well enough to put AI to work and still keep control of that data?
Reviews of AI tools usually start with the tool’s security. That review is necessary, but it can leave the more consequential questions about the organization deploying the tool unanswered. Important questions to answer before evaluating the AI tool include, (1) what information the tool will be able to reach, (2) what the organization and its vendor may do with that information, and (3) who has authority to change either one.
What Control Means
Control is an organization’s ability to know what data it holds and to make enforceable decisions about how that data is used. It has four components:
- Inventory. The organization knows what data it holds and where that data resides.
- Access. It knows which people, systems, and tools can reach that data.
- Use. It has set rules for how the data may be used, and it can confirm those rules are followed.
- Vendor commitments. It knows what its service providers have agreed to do with the data, and what they have agreed not to do.
Each component rests on existing requirements and frameworks. For example, the GLBA Safeguards Rule applies to most colleges and universities through their participation in federal student aid programs. It already requires covered institutions to identify and manage their data, personnel, devices, systems, and facilities according to their importance to business objectives and risk strategy. Similarly, NIST’s Cybersecurity Framework 2.0 calls for maintaining inventories of data and corresponding metadata for designated data types, along with representations of internal and external data flows. NIST’s AI Risk Management Framework adds an inventory of AI systems and policies addressing risks from third-party software and data. While these frameworks are helpful to understand and they can offer organizations a strong foundation, they do not solve for certain pillars of the control framework,
These frameworks give organizations a strong foundation. What they cannot do is determine, within a particular organization, who approves a new use of data, who acts when a problem surfaces, and who verifies that the problem has been corrected..
Why AI Raises the Stakes
A control gap is a weakness in any of the four components of control. The organization holds data it cannot account for or no longer needs. Access is broader than anyone intended. Data is used for purposes that have drifted from the reason it was collected. Or vendor commitments are no longer being monitored after signature. These gaps generally exist before an AI tool arrives, and AI makes them easier to encounter:
- Content that was technically available to broad groups of users, but practically obscure, becomes retrievable through a single query.
- Data collected for one purpose becomes attractive for another.
- Product updates introduce new features, new data flows, and new subprocessors without a new procurement decision.
Regulators are also looking more closely at how systems actually use personal information. California’s regulations, effective January 1, 2026, require covered businesses to conduct a risk assessment before starting processing that presents significant risk to consumer privacy. Beginning January 1, 2027, they impose additional requirements on businesses that use automated decision making technology for significant decisions. The California rules will not apply to every organization. They do reflect a clear direction: legal obligations increasingly depend on the purpose and effect of a particular use.
Framing the Analysis: Start with a Use
A complete, organization-wide data inventory is the right long-term goal, but organizations do not need to finish one before evaluating an AI tool. We recommend starting with the specific use under consideration and mapping the data that use would involve: what the tool could reach, where that data came from, and who can access it today. That analysis supports the immediate decision, and each review adds to the broader inventory over time.
Consider a hypothetical. A university’s advising office wants an AI assistant to help draft outreach to students who may be at risk of leaving. They request to connect the assistant to the office’s shared drive. A useful analysis examines five questions about that specific use, and each answer has consequences for the decision.
- What the tool could reach, not only what the office intends it to use. If the shared drive also holds financial aid documents or old exports from the student information system, the tool can reach those too. The deployment then touches customer information covered by the institution’s Safeguards program. The review has to account for that data, and the institution may need to restrict the tool to specific folders before connecting it.
- Why the data was collected, and whether the proposed use is consistent with that purpose. Records gathered to administer financial aid were not gathered to predict attrition. Using them for that purpose may require additional disclosures or consent, depending on what the institution told students and which legal restrictions apply to the data.
- Whether the tool widens access in practice. Staff may have had technical access to the entire drive but rarely opened most of it. A tool that searches all of it changes who effectively sees what, and it can surface records to people with no need to know them. Permissions may need to be corrected before deployment, not after.
- What the vendor may do with prompts, files, and outputs. This includes how long the vendor retains them and whether it may use them to train or improve its models. If the terms permit uses the institution would not accept, the options are to negotiate the contract, change the product configuration, select a different service tier, or choose another tool.
- Who decides. Someone must have authority to approve the use, narrow it, or decline it, and that decision should be documented along with any conditions attached. Without a designated decision-maker, the use tends either to proceed by default or to stall.
The analysis should end in one of three outcomes. The institution approves the use as proposed, approves it with conditions such as narrower permissions or revised contract terms, or declines it until the underlying gaps are addressed.
Building Data Knowledge into the Organization
Implementation depends on an organization’s size and maturity. The following steps apply in most settings.
- Identify the AI already in use. Before approving new tools, list the ones in use today. Include AI features that arrived through updates to software the organization already licenses, since those can appear without any procurement decision.
- Assign an owner to every approved tool. Each tool needs a named business owner accountable for how it is used and a technical contact who can confirm what it is connected to. If no one will accept that role, that is relevant to whether the organization is ready to deploy the tool.
- Test the tool’s reach before rollout. Run the tool under an ordinary user’s account and review what it returns. The results are a practical preview of existing permission problems. We address this step in detail next week.
- Decide in advance where findings go. When a test or a user surfaces information that should not be visible, the organization should already know who receives the report, who decides whether to pause deployment, and who confirms the fix.
- Build on existing governance. The Safeguards Rule already requires covered institutions to periodically review their data retention policies to minimize unnecessary retention. It also requires them to periodically assess service providers based on the risk they present. The AI tool inventory belongs alongside those records, maintained by the same personnel on the same review cycle, rather than in a separate program that falls out of date.
None of these steps requires a finished data map. Each one contributes information the organization needs to build its comprehensive map.
What’s Next
Over the next four weeks, we will take each component of control in turn: knowing your data, identifying the gaps AI exposes, setting internal rules, and holding vendors to clear commitments.
Sources: 16 C.F.R. § 314.4(c)(2), (c)(6)(ii), (f)(3); NIST CSF 2.0, ID.AM-03 and ID.AM-07; NIST AI RMF 1.0, GOVERN 1.6 and 6; California Privacy Protection Agency, CCPA regulations on risk assessments and ADMT (effective Jan. 1, 2026)
