You prove it with a record that was made when the request was sent, that you hold rather than the AI vendor, that names who sent it, through which AI service, and when, that keeps the content of what was sent, and that shows if anyone changed it afterward. A vendor’s chat history, a screenshot, or a policy that says staff should not paste sensitive data each supports part of the story. None of them, alone, shows what a model actually received. No regulator we found prescribes this exact record. The rules that apply to banks, credit unions, and health systems ask for the ingredients: activity records you can examine, review, and keep.
Proving an input means answering four things: who sent it, to which service, when, and what it contained. The fourth is the one most institutions cannot answer today.
What does it take to prove what an AI model received?
Three properties, and a record that lacks any of them is weaker than it looks.
- Content. The prompt, the files, and the pasted material, or a faithful account of them. A log that says a user visited an AI site on a Tuesday shows a visit, not an input.
- Attribution. Which person, on which device, through which AI service, at what time. Without attribution, content is an anonymous string.
- Integrity. Some way to tell whether the entry was changed after it was written. A record you can edit without a trace is a note, not evidence.
The record also has to be yours. Evidence you must ask a vendor to produce is evidence on the vendor’s schedule and terms, and a vendor’s history exists in whatever form and for however long its product settings and contract say.
What do the rules require for health systems?
The HIPAA Security Rule asks for audit controls: under 45 CFR 164.312(b), a covered entity or business associate must “implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.” Under 164.308(a)(1)(ii)(D), it must implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports. And under 164.316(b), documentation the subpart requires must be kept in written or electronic form for six years from the date it was created or last in effect.
None of that text mentions AI. Whether a prompt to an AI tool is activity in an information system that contains or uses electronic protected health information depends on where the tool runs and what was in the prompt, and the regulator, not this page, decides how the standard applies. Our sibling post on whether HIPAA requires logging what an AI model received takes that question on directly. For this page, the useful point is narrower: if you ever have to explain a disclosure, the record above is what you would want in hand.
What do the rules require for credit unions?
Appendix A to 12 CFR Part 748 asks a federally insured credit union to consider monitoring systems and procedures to detect actual and attempted attacks on or intrusions into member information systems (III.C.1.f), to regularly test key controls (III.C.3), and, for service providers, to monitor them where its risk assessment indicates by reviewing audits, summaries of test results, or equivalent evaluations (III.D.3). It also asks for response programs when unauthorized access to member information is suspected (III.C.1.g). Each of those is easier to carry out when there is a record of what left the institution. The appendix does not name AI, and it does not say what such a record must contain.
What do the rules require for banks?
The 2023 Interagency Guidance on Third-Party Relationships, issued by the Federal Reserve Board, the FDIC, and the OCC, lists what supports documentation and reporting for a third-party relationship: an inventory of relationships, risk assessments, due diligence results, executed contracts, monitoring reports, reports of service disruptions or security breaches, and periodic reporting to the board. It does not mention prompts or inputs, and its preamble mentions artificial intelligence only in describing suggestions from commenters. On September 15, 2026, the OCC, the Board, the FDIC, and the NCUA published a proposal to rescind and replace that guidance, with comments due November 16, 2026. A bank’s obligation to keep an accurate picture of what it sends to a third party comes from that framework and from its general safety and soundness duties. What the content of the record must be is left to the bank’s own judgment.
Why is a vendor’s chat history not enough?
Because it answers a different question. A vendor’s history shows what the vendor chose to keep of a session in an account. It does not show, from your side, what left your devices, who sent it under which identity, or whether the history you are reading is the history that existed at the time. It also covers only the vendor’s own service, so it cannot describe AI use across the several tools your people actually use. Consumer and business accounts with the same vendor can differ in what they retain and who can see it, so check the current terms for the exact account type rather than assuming.
What does tamper-evident add, and what does it not prove?
A tamper-evident record is built so that altering an entry breaks a check. Each entry is signed at the source and chained to the one before it, so a changed entry or a gap in the chain shows up when the chain is checked. NIST’s Guide to Computer Security Log Management (SP 800-92, 2006) is the general reference for running log management in an organization, and the integrity question it raises is the same one here.
Be exact about the limit. Tamper-evidence detects alteration of captured entries. It does not prove that everything was captured, it cannot see the removal of the newest entries without an outside anchor, and it cannot show what happened on a device or through a tool that never reached the capture point. Say “every captured interaction,” and know which tools and devices are inside that boundary before you rely on the record in front of an examiner.
Does redaction change what you can prove?
It changes what the model was given. If a tool screens a Social Security number or a card number before a prompt leaves the device, the model received the placeholder, not the number, and the record of what it was given should say so. Decide in advance which version the record must hold and write that down. Redaction of that kind works on patterns, so treat it as best-effort. It lowers what a model receives; it does not settle what it received, and only the record does.
What you need in place
- A list of the AI services your people can reach and the devices you manage, so you know what is inside the boundary of any record.
- A capture point that sees requests as they are sent, on devices you manage, rather than relying on each vendor’s history.
- Entries that name the person, device, AI service, and time, and keep the content under keys your institution holds.
- A way to check integrity that runs on your own infrastructure and that someone owns.
- A written decision on what the record holds when a value was screened before sending, and how long records are kept.
- A statement, in your policy, of what the record does not cover, so no one mistakes it for a complete account of all AI use.
Related reading: what an AI audit trail must answer, and why a business associate agreement is necessary but not sufficient. For the credit union view, see whether staff can put member data into ChatGPT.
Sources
- 45 CFR 164.312(b), Audit controls; 164.308(a)(1)(ii)(D), Information system activity review; 164.316(b), Documentation. eCFR, Part 164 Subpart C, read September 28, 2026.
- 12 CFR Part 748, Appendix A, sections III.C.1.f, III.C.1.g, III.C.3, and III.D.3. eCFR, read September 28, 2026.
- Board, FDIC, and OCC, Interagency Guidance on Third-Party Relationships: Risk Management, 88 FR 37920 (June 9, 2023), section D.3, Documentation and Reporting. Federal Register, read September 28, 2026.
- OCC, Board, FDIC, and NCUA, Proposed Third-Party Risk Management Guidance, 91 FR 58536 (September 15, 2026), comments due November 16, 2026. Federal Register, read September 28, 2026.
- NIST, Special Publication 800-92, Guide to Computer Security Log Management (September 2006). NIST CSRC, read September 28, 2026.
Where Verillian fits
Verillian governs AI use on the devices you enroll. A checkpoint on each device sits between your people’s AI tools and agents and the AI providers it supports. For Claude and Claude Code traffic (the Anthropic API format), a tool call your policy bans is removed before your machine can run it; for the other supported providers, it screens and records the usage, and the Claude desktop app and Cursor are recorded only, with no redaction. Each record is signed on the device it came from and hash-chained to the one before it, so a change to its signed fields is detectable, and it stays on your own infrastructure. It cannot show that nothing was omitted. Redaction is best-effort, not a guarantee that every value is caught. The admin server runs where you choose: on-prem or in a private cloud you run. macOS is the supported install today; Windows has an interim scripted installer and Linux builds from source.
For this question, that record is the part of the list above that names, for each captured interaction, the user and device the checkpoint reports, the service, and the time, with content encrypted under keys you hold wherever the checkpoint can read it; the Claude desktop app and Cursor, for example, are recorded without their content. It covers AI use that reaches the checkpoint, so which of your tools and devices are inside that boundary is worth confirming first. The architecture is aligned with the audit control expectations in the HIPAA Security Rule and Appendix A, not certified, because those provisions set duties for the institution’s own program and do not certify a product.
Verillian does not see inside a vendor’s own cloud. When a vendor’s service calls a model on the vendor’s servers, as an ambient scribe or a hosted report-writing tool does, the record of what that model received is created on the vendor’s side, and the contract is your lever for it. What Verillian gives you is the record of AI use that starts on your own devices.
Our compliance mappings show the controls the platform is designed to support, the audit trail page shows what a device-side record contains, and the demo shows a record being made on a real device.
