A
Adam Bertram
Guest
AI governance is more than approving the model. It is showing evidence of where the model’s data came from and who was allowed to send it.
Most AI governance reviews spend their energy on the model. Wrong place to look. When an examiner asks how a sensitive training file left a core banking system, “the model was approved” is not an answer. Banks need to provide records about the file’s history.
The model is the part you can already account for: it was reviewed and approved, with the paperwork in the drawer if anyone asks.
The part nobody can account for is the data the model learned from. Where did it come from, and who was allowed to send it? And when one system handed that data to another, did anything record that the handoff happened at all? Approving a model answers none of that. The data moved long before the model ever saw it, and there may be no audit-ready record of how the file left the bank.
So follow the data backward. Before the model trained on that file, one system sent it and another received it. That’s the last place you can still see who released it and whether they were allowed to.
That moment has a name: a file transfer. Every transfer has a boundary, the point where data leaves one system and enters another. That boundary is where governance stops being a written policy and turns into a question of custody: who sent the file, who received it, what path it took, how it was protected and what proof of all that still exists months later. A model review can’t answer one of those; by then, the file crossed that boundary long ago.
You would expect the most cited AI governance framework to cover this. It nearly does. The NIST AI Risk Management Framework (AI RMF) treats trustworthiness as something you manage across design, development, use and evaluation, not certify once and file away. But it stays at policy level: it tells you to manage risk, not how to document evidence that a given file was authorized to move on a given night.
If the missing piece is proof that a file moved the way it was supposed to, the discipline you want is built around moving files. That is Managed File Transfer (MFT): it helps govern how files move between systems and can record file activity while it happens, so a transfer becomes something you authorized in advance and can replay on demand. Progress Automate MFT is one way to do that without turning every exception into a forensic project.
So there are two jobs here, and confusing them is how the data gap opens:
When an auditor or security lead asks about a transfer, they are not interested in your architecture diagram. They want the answers that demonstrate custody, and those answers live in what the transfer recorded about itself.
Every month, one file leaves a core banking system for the analytics workspace where a model runs. Call it the model-risk extract. The first review question is not “did the file arrive?” It is “can we reconstruct the move without relying only on memory?”
That move runs as a scheduled task, and the task keeps a record. Start there, and do not stop at the status column. The Task Run and File Activity reports log status, timing, how or by whom the run was started, file names and source and destination paths. The status column is where reviews go quiet. That 02:10 run reports Success, and every dashboard is satisfied. But Success only indicates the file was delivered, not where it came from. If you re-point the network share that the task reads from and it still completes, still reports green, you’re now feeding the workspace a file the approved source never produced. The check is true and the lineage is wrong.
The source path is one field that can help identify this issue. The extract is supposed to come from exactly one directory, and the report can log the source path for runs. So custody is not “did it succeed?” It is “does the logged source path match the one approved path, on every run this quarter?” One mismatched path could be the difference between a transfer you can defend and a finding you cannot.
Then prove the authority behind the path. Role-based access control (RBAC) assigns permissions at the folder level, so the task’s record sits next to the permission that let someone run it. And when the question turns from “who ran the transfer?” to “who changed it before it ran?”, the Audit reports record user actions across system and task activity. Identity and keys sit underneath, but custody rests on the logged path and the permission behind it.
A smart skeptic will say governance belongs with the model team, because that is where model drift and hallucinated output live. They have a point, and a rulebook behind it: banking regulators treat model risk management as a defined discipline, with formal expectations for how large banks develop, validate and govern models. The objection is not wrong. It is incomplete.
Model governance decides what the system may infer. Transfer governance helps show evidence for what model approval never touches: that the input was legitimate and authorized when it moved, with evidence that survives to the next audit. Stop at model approvals and you may have controlled the answer while ignoring the source, destination and user actions that got it there.
The real test is not whether your team can name the policy. It is whether the path can be rebuilt without guessing which key protected the transfer and which permission allowed the operator who ran it. Those records can feed the risk and operations systems your teams already use, instead of sitting in a console nobody opens.
It still hands the model team a cleaner record, so the review can focus on the answer’s quality, not on defending the file behind it.
Treat the transfer as the boundary and the conversation sharpens. Partner onboarding stops being “can we get the file there?” and becomes “can we show records of who sent it and how it was protected after it is gone?” And audit requests stop being scavenger hunts when the record that answers them was written the moment the file moved.
This isn’t hypothetical. PaperTrl, which moves ACH files on behalf of banks, swapped hand-maintained transfer scripts for Automate MFT, whose detailed logging and audit trails help support PaperTrl’s efforts related to SOC 2 and GLBA requirements.
The lesson is unglamorous and it holds: put enforcement near the transfer and keep the evidence under disciplined log management where governance teams can find it before the auditor does.
So pick one transfer path that matters and prove you can account for it end to end:
Prove that one path first. Once records can support review of the file that left the bank, the conversation about the model gets easier, not harder.
Continue reading...
Most AI governance reviews spend their energy on the model. Wrong place to look. When an examiner asks how a sensitive training file left a core banking system, “the model was approved” is not an answer. Banks need to provide records about the file’s history.
The model is the part you can already account for: it was reviewed and approved, with the paperwork in the drawer if anyone asks.
The part nobody can account for is the data the model learned from. Where did it come from, and who was allowed to send it? And when one system handed that data to another, did anything record that the handoff happened at all? Approving a model answers none of that. The data moved long before the model ever saw it, and there may be no audit-ready record of how the file left the bank.
Govern the Move, Not Just the Model
So follow the data backward. Before the model trained on that file, one system sent it and another received it. That’s the last place you can still see who released it and whether they were allowed to.
That moment has a name: a file transfer. Every transfer has a boundary, the point where data leaves one system and enters another. That boundary is where governance stops being a written policy and turns into a question of custody: who sent the file, who received it, what path it took, how it was protected and what proof of all that still exists months later. A model review can’t answer one of those; by then, the file crossed that boundary long ago.
You would expect the most cited AI governance framework to cover this. It nearly does. The NIST AI Risk Management Framework (AI RMF) treats trustworthiness as something you manage across design, development, use and evaluation, not certify once and file away. But it stays at policy level: it tells you to manage risk, not how to document evidence that a given file was authorized to move on a given night.
If the missing piece is proof that a file moved the way it was supposed to, the discipline you want is built around moving files. That is Managed File Transfer (MFT): it helps govern how files move between systems and can record file activity while it happens, so a transfer becomes something you authorized in advance and can replay on demand. Progress Automate MFT is one way to do that without turning every exception into a forensic project.
So there are two jobs here, and confusing them is how the data gap opens:
- Model governance asks whether the system should exist at all: is the model sound, and is it cleared to run?
- Transfer governance asks whether the data the model learned from was authorized to move, and whether that move can be reconstructed afterward.
What the Transfer’s Record Has to Answer
When an auditor or security lead asks about a transfer, they are not interested in your architecture diagram. They want the answers that demonstrate custody, and those answers live in what the transfer recorded about itself.
Every month, one file leaves a core banking system for the analytics workspace where a model runs. Call it the model-risk extract. The first review question is not “did the file arrive?” It is “can we reconstruct the move without relying only on memory?”
That move runs as a scheduled task, and the task keeps a record. Start there, and do not stop at the status column. The Task Run and File Activity reports log status, timing, how or by whom the run was started, file names and source and destination paths. The status column is where reviews go quiet. That 02:10 run reports Success, and every dashboard is satisfied. But Success only indicates the file was delivered, not where it came from. If you re-point the network share that the task reads from and it still completes, still reports green, you’re now feeding the workspace a file the approved source never produced. The check is true and the lineage is wrong.
The source path is one field that can help identify this issue. The extract is supposed to come from exactly one directory, and the report can log the source path for runs. So custody is not “did it succeed?” It is “does the logged source path match the one approved path, on every run this quarter?” One mismatched path could be the difference between a transfer you can defend and a finding you cannot.
Then prove the authority behind the path. Role-based access control (RBAC) assigns permissions at the folder level, so the task’s record sits next to the permission that let someone run it. And when the question turns from “who ran the transfer?” to “who changed it before it ran?”, the Audit reports record user actions across system and task activity. Identity and keys sit underneath, but custody rests on the logged path and the permission behind it.
But Isn’t This the Model Team’s Job?
A smart skeptic will say governance belongs with the model team, because that is where model drift and hallucinated output live. They have a point, and a rulebook behind it: banking regulators treat model risk management as a defined discipline, with formal expectations for how large banks develop, validate and govern models. The objection is not wrong. It is incomplete.
Model governance decides what the system may infer. Transfer governance helps show evidence for what model approval never touches: that the input was legitimate and authorized when it moved, with evidence that survives to the next audit. Stop at model approvals and you may have controlled the answer while ignoring the source, destination and user actions that got it there.
The real test is not whether your team can name the policy. It is whether the path can be rebuilt without guessing which key protected the transfer and which permission allowed the operator who ran it. Those records can feed the risk and operations systems your teams already use, instead of sitting in a console nobody opens.
It still hands the model team a cleaner record, so the review can focus on the answer’s quality, not on defending the file behind it.
What Changes Once You Govern the Move
Treat the transfer as the boundary and the conversation sharpens. Partner onboarding stops being “can we get the file there?” and becomes “can we show records of who sent it and how it was protected after it is gone?” And audit requests stop being scavenger hunts when the record that answers them was written the moment the file moved.
This isn’t hypothetical. PaperTrl, which moves ACH files on behalf of banks, swapped hand-maintained transfer scripts for Automate MFT, whose detailed logging and audit trails help support PaperTrl’s efforts related to SOC 2 and GLBA requirements.
The lesson is unglamorous and it holds: put enforcement near the transfer and keep the evidence under disciplined log management where governance teams can find it before the auditor does.
So pick one transfer path that matters and prove you can account for it end to end:
- the source and destination for the task
- the task record: when it ran, whether it succeeded, what moved and who started it
- the folder role that let the operator run it
- the key or certificate tied to the endpoint
- the audit trail for any configuration change
- what happens when the task fails or is rerun
Prove that one path first. Once records can support review of the file that left the bank, the conversation about the model gets easier, not harder.
Continue reading...