How to run an AI data call

You cannot govern what you cannot see, and right now most of the AI touching your institution's data got there without a purchase order. Someone connected a note-taker to their calendar. Someone pasted a member's loan file into a chatbot to "reword the denial letter nicely." A vendor you've used for six years quietly turned on an AI feature in a product update. None of it went through you.

The first move in any AI governance program is the least glamorous one: build an honest list of what AI your people actually use. Not what policy says they should use — what they do use. Practitioners call this a data call: a structured request for information from every corner of the institution, cross-checked against system evidence so you're not just trusting self-reports. This playbook is how to run one when you're a compliance or risk officer without a CISO, a SOC, or a spare quarter.

The stakes are concrete. Ncontracts' 2026 State of TPRM survey (n=173) found that 72% of financial institutions are only partially aware of which of their vendors use AI, and 0% called themselves "extremely confident" managing that risk. AI risk tied cybersecurity as the top third-party concern for the first time. You are not behind because you're careless. You're behind because the surface moved and nobody handed you a map.

Before you start: scope it to a week, not a project

A perfect inventory that takes six months is worse than a good-enough one you finish Friday. Give yourself a five-business-day box. The output is a single spreadsheet — the AI inventory — with one row per tool and these columns: tool name, vendor, who uses it, what data it touches, how it got in (approved / feature-flip / shadow), data retention if known, whether you hold a SOC 2 or equivalent, and a risk flag (high / medium / low) you'll assign at the end. Everything below feeds that sheet.

Step 1 — The human data call (Day 1)

Send a short, plain-language request to every department head and, if your institution is small enough, every employee. Keep it non-punitive; the moment this feels like a hunt for who broke a rule, the honest answers stop.

Ask exactly four questions:

1. What software do you use that writes, summarizes, transcribes, drafts, or "suggests" things for you? (This phrasing catches AI features people don't think of as "AI.")
2. Have you ever pasted member, customer, or account information into a chatbot or website to get help with it?
3. What tools have you connected to your work email, calendar, or file storage — meeting note-takers, scheduling assistants, CRM plug-ins?
4. What did a vendor turn on this year that you didn't ask for — a new "AI assistant," "smart summary," or "Copilot" button?

Give them a two-day window and a named human to reply to. You will get partial, honest answers. That's the point — this is the layer system evidence can't see, like the analyst pasting text into a consumer chatbot on their phone.

Step 2 — The system data call (Days 2–3)

Self-reports miss things and understate scope. Now you corroborate against what the systems actually show. Three sources cover most of what a small institution runs:

OAuth / third-party app grants. This is the single highest-yield source, because it shows AI tools that connected themselves to your data with a user's click. In Google Workspace, an admin goes to Reporting → Audit and investigation → OAuth log events to see each time a third-party app was authorized, and Security → Access and data control → API controls → App access control to see each app, its scopes, and which users granted them (Google). In Microsoft Entra ID, go to Entra ID → Enterprise applications → All applications, open an app, and read the Permissions tab to see what it can reach and whether consent was granted for one user or the whole tenant (Microsoft). We give this its own full playbook — see Reading OAuth grants — the shadow-AI map in your Workspace and Entra — because it's where the surprises live.

Your existing vendor list. Pull your current third-party inventory and, for each vendor, check whether they shipped an AI feature this year. The fastest path is their release notes, their trust/security page, and their DPA. Flag any "assistant," "summary," "insights," or "Copilot" language. Your vendors are adding AI without telling you — treat every renewal as a re-diligence trigger.

Expense and procurement records. Search card statements and AP for the names of common AI SaaS — chatbots, transcription, scheduling assistants, writing tools. A $20/month line item is often a whole department's shadow-AI habit with a receipt.

Step 3 — The canonical find, and what to do with it

Here is the kind of row this exercise surfaces, and it's worth walking through because it's typical:

> Otter.ai holds Calendar + Drive read access for 8 users since March; meeting recordings are retained; no SOC 2 on file.

Unpack what that one line tells you. A meeting transcription tool has standing, ongoing read access to eight employees' calendars and files — not a one-time export, a live grant it can use whenever it likes. It's been there since March, so months of meetings (member reviews, board prep, HR conversations) may have been recorded and retained on the vendor's infrastructure. And you have no SOC 2, so you cannot say how that data is stored, who at the vendor can see it, or whether it's used to train models. Nobody approved this. A user clicked "allow" to save themselves note-taking.

That's not a scandal — it's a finding. You log it: tool = Otter.ai, data = calendar + drive (read), users = 8, retention = recordings retained (confirm), evidence = none on file, flag = high. Then it enters your remediation queue (revoke, restrict scope, or diligence-and-approve) and your evidence binder as a documented, dated observation. See What an examiner-ready AI evidence binder contains for where it lands.

Step 4 — Triage, don't boil the ocean (Day 4)

You now have a list, probably longer than you expected. Rank it. NCUA's diligence framework has said for years that oversight should be proportional to the vendor's risk — 07-CU-13 explicitly allows "reasonable alternative procedures" and less analysis for non-complex, non-core relationships. RIAs get to the same place through Reg S-P's "reasonable" standard. So sort by two axes: sensitivity of data touched and standing level of access. A tool with read/write access to member PII outranks a grammar checker on marketing copy, every time. Put your finite hours on the top of that list.

Step 5 — Close the loop (Day 5)

Three outputs make this real:

• The inventory sheet, dated and saved where it can be re-run next quarter. A data call is not a one-time event; it's a baseline you diff against. Your AI surface expands silently, so the value is in comparing March to June.
• A one-page summary for your board or principal: how many AI tools found, how many were shadow (nobody approved), how many touch sensitive data, top three risks. This is the artifact that answers "what are we doing about AI?" in a meeting.
• A remediation queue — the high flags, each with an owner and a next step (revoke, restrict, diligence, or accept-and-document).

The honest part

A data call gives you a point-in-time inventory, and it's only as complete as your sources. It will not catch AI a vendor runs entirely on their own backend with no visible feature and no new data grant — you find that through vendor due diligence, not a scan (see The AI vendor due-diligence questions that actually matter). It won't catch a determined employee using a personal device off your network. And it tells you a tool exists, not whether it's safe — that's the next layer of work, mapping each tool to what it actually does with data. An inventory is the floor, not the ceiling. But it is the floor, and most institutions don't have it yet.

If assembling and re-running this every quarter is more than a 1–2 person program can carry, that's the labor a Discover scan is built to relieve: we run the data call with you, read the OAuth grants, and hand back the dated inventory and the flagged findings as evidence you can put in front of an examiner. The read-only scan is the same one described above — done once, thoroughly, with the research library behind every Discover report telling you what each vendor actually does with data.

Request your Discover scan — we run it with you. Or do it yourself this week: pull your own OAuth grants using Reading OAuth grants — the shadow-AI map in your Workspace and Entra.