On October 15, the Financial Stability Board finalized 12 sound practices for how banks and other financial institutions adopt AI. The practices cover board oversight, clear roles, human oversight, and third-party risk. Two practices go further on data. One describes the stages data should pass through before an AI use case goes live. The other names the events that should send a firm back to check performance again, including changes to the model or its data.
Read together, the two practices describe data that stays fit for purpose for a use case, assessed before deployment and assessed again when the model, its data, or real-world conditions change. Our reading: AI-ready data needs evidence of fitness for a specific use case, with that evidence reviewed when relevant conditions change.
Key takeaways
- The FSB finalized 12 sound practices for responsible AI adoption on October 15, 2026. The report says they are non-prescriptive and do not form a binding international standard.
- The data governance practice describes stages from an initial suitability check through a quality assessment after preparation and before deployment, then monitoring after deployment, with key steps documented as data lineage.
- The performance practice asks firms to set thresholds before outputs exist where possible and to adjust assessments after recent changes to the model, system, or data, or to real-world conditions.
- In practice, keep the record that links the prepared data version, the evaluation conditions, the thresholds, and the result, so you can assess what a change affects.
What the FSB’s final AI report covers
The final report groups the practices into organization-wide governance and risk management across the AI lifecycle, and it adds considerations for agentic AI. The FSB calls the practices a toolkit that firms tailor to their context, not an international standard. For agents, it describes record-keeping that shows what triggered an action and what information and tools the agent used. That is the same question the data practices raise at the level of a use case: what stood behind this result?
What the AI data governance practice asks, stage by stage
Practice 7 asks for data that stays fit for purpose for training, testing, and using AI. The report then lists the stages below. The middle column summarizes the report. The right column is our practical reading of the evidence each stage leaves behind, not FSB wording.
| Stage in the report | What the report describes | Evidence to keep (CUBIG practical reading) |
|---|---|---|
| Initial assessment | Availability, quality, quantity, and suitability of data for the AI use case | The use case, the data it needs, and the gaps found before work starts |
| Collection and provenance | Where data came from, with due diligence on public and third-party data | Source and extract date for each input |
| Classification | Materiality, risk, sensitivity, and intended and prohibited uses of the data | Permitted and prohibited uses recorded for each input the use case relies on |
| Preparation | Aggregating, labeling, cleaning, enriching, or updating, described as the most resource intensive stage | The preparation rules applied and the version they produced |
| Quality assessment before deployment | After preparation, identify gaps and limitations and how they are mitigated | Results before and after preparation under the same evaluation conditions, against thresholds set in advance |
| Monitoring after deployment | Find and fix problems caused by data issues such as data drift | Which version is in use, and the baseline to rerun when something changes |
| Documentation (data lineage) | How data is transformed and used, to support audit and root cause analysis | One record linking source, version, conditions, and result |
Where AI-ready data checks break down after a change
Monitoring after deployment shows that results moved, but on its own it rarely shows whether the data, the model, or the world caused it. Practice 9 lists recent changes to the model, system, or data, and significant changes to real-world conditions, as reasons to adjust how a use case is assessed. Practice 5 adds that materiality should be reassessed at regular intervals and at events such as scaling a use case into critical operations. Each of those triggers raises the same first question: which data version and evaluation conditions stood behind the result you approved?
- 01Approve
A use case passes thresholds set in advance, on one prepared data version.
- 02Change
A source table adds a field, or the model behind the task is updated.
- 03Go back
Review the recorded baseline and conditions, then repeat the evaluation where possible.
- 04Decide
Keep using it, recheck the affected part, or prepare a new version.
Without that record, teams may need broader revalidation because they cannot justify a narrower scope. With it, they can compare against the recorded baseline and assess whether a targeted recheck is sufficient. Our article on deciding what to revalidate after a data change walks through that decision, and the same logic applies when the model changes underneath a task.
What the report does not do
- Set a rule you must follow. The practices are non-binding, and the report says applying them does not replace local legal and regulatory requirements.
- Say that data is the only cause. The same practices cover model selection, explainability, human oversight, and third-party dependencies, and any of these can move a result.
- Prescribe tools. The report describes outcomes and stages. How you record versions, thresholds, and baselines is left to each firm.
How to prepare evidence before your next AI review
These steps follow the stages above and work with your existing tools. They also apply outside financial services.
- Write the use case and its thresholds before the run. Agree on what passing means for this task before anyone sees the output.
- Pin the data version behind the result. Record which prepared version, with which preparation rules, produced the output you approve.
- Record a baseline under fixed evaluation conditions. Keep the evaluation set, settings, and scores together so you can run the same check again.
- List your change triggers and define what each one requires you to recheck. A source update, a schema change, a model update, or wider use each points to a different recheck.
For UK firms, the model data expectations in PRA SS1/23 point in the same direction from a model risk angle. For what AI-ready data means beyond clean data, see What Is AI-Ready Data?
Related product: Syntitan
For structured data, CUBIG’s Syntitan keeps the preparation side of this record. Teams set up a Project for one use case and work on a copy of the original Dataset. Each successful preparation run creates a new data Version. Ready for Model compares results before and after preparation using the same model and evaluation conditions, then checks whether the agreed criteria are met. Tracing a later change back to the Version and conditions behind a result, and assessing what needs to be revalidated after a change, is planned for December. Syntitan does not decide materiality or risk appetite, and it does not make a firm compliant; those decisions stay with your risk and compliance teams.
