Model management covers the full model life cycle, from data collection and training through deployment, monitoring, replacement, and audit evidence.
2
Financial models need controls that match their risk, with stronger governance for models that affect customers' finances, credit scores, or personally identifiable information.
3
Teams need both automated checks and human review because data drift, broken upstream pipelines, and genuine changes in the business can look similar.
Summary
This round-table discussion explains model management as the work of tracking a model from its training data and evaluations through deployment, monitoring, replacement, and audit. Michelle Marie Conway describes Lloyd's Banking Group's risk-based governance, where models affecting customer finances receive more scrutiny than internal forecasts. Oliver Chipperfield explains why loan-loss forecasting needs manual validation, since market changes, upstream data problems, and real shifts in customer behaviour can produce similar signals. Darek Kłeczek argues that experiment tracking and model registries create reproducibility, lineage, and documentation with relatively little extra code. Mark Huang discusses the added difficulty of managing large language models, where training updates are expensive and reproducibility depends on data, model shards, formats, and hardware. The panel also covers explainability, custom evaluations, stakeholder involvement, and team structure. Its practical message is that automation helps, but regulated systems still need clear ownership, business review, and evidence that a model did what the organisation expected.
Model management follows a model through its entire life cycle
Darek Kłeczek defines model management as the processes and tools used across training, evaluation, deployment, monitoring, and replacement. Teams need to collect a dataset, choose an algorithm, save the trained model, test it for risks and bias, and monitor it in production. A challenger model may later replace the current one. In a regulated setting, an audit requires the team to explain how the model came together, which evaluations it passed, and how it was tested for specific risks. Oliver Chipperfield agrees with this life-cycle view and describes it as the progression from incubation to building, deployment, and production.
Regulated models need controls that match their effect on people
Oliver Chipperfield says financial services depends on auditability. A forecast must be justified, and the team must trace where its data came from. Michelle Marie Conway explains that Lloyd's Banking Group uses risk levels from one to four, with level one being the most severe. Models that affect a customer's finances or credit score receive more governance. The modelling method also matters. A black-box model may need more explanation than a simpler model. Personally identifiable information, such as age, date of birth, postcode, bank-account details, or medical notes, also affects the risk assessment. Conway describes regular risk-committee reviews and annual model assessments rather than waiting for an occasional audit.
Large language models make updates and reproducibility harder
Mark Huang says the size of the data and models changes the management problem for large language models. Traditional models can often be rolled back, updated, or retrained relatively easily. An LLM update can cost tens or hundreds of thousands of dollars, and the team cannot easily predict what new data will do to the model. The panel discusses model unlearning as an area that is still being researched, especially when a model needs to forget private or outdated information while retaining useful capabilities. Huang also points to practical reproducibility problems involving model sharding, floating-point formats, hardware, checkpoint restarts, and serialization.
Private LLM deployments must prevent sensitive data from leaving the organisation
Michelle Marie Conway says her bank cannot use ChatGPT internally for tasks such as writing a risk report because the prompt data could leave the bank. The value of LLMs in finance therefore depends on controlling where data goes and how the models are isolated. Demetrios Brinkmann adds that even a model inside a protected environment can produce unexpected outputs, including personally identifiable information after an unusual prompt. Mark Huang says teams are using open-source Llama models because they come in different sizes and have broad usage, while some teams are also testing multimodal models such as YUU and open-source reproductions of LLaVA.
Forecasting systems need automated checks alongside human approval
Oliver Chipperfield describes a loan-loss forecasting process where small changes in a forecast can have large financial effects. The team moved from manual retraining to an automated process using Weights & Biases, followed by validation checks. A quality-assurance step still requires a person to inspect the model and data before release to stakeholders. The market adds difficulty because currency problems, macroeconomic changes, aggressive competition, business growth, and a broader customer base can all change the forecasts. The team must distinguish those real shifts from broken upstream data, duplicated records, or other pipeline bugs. Chipperfield says a human still needs to justify the forecast before it reaches reporting and business users.
Data drift and data breakage require different checks
Chipperfield separates a change in the feature distribution from a broken data model. The team uses thresholds to flag large differences between a challenger and current model or between forecasts from different days. It plans to add more formal feature-drift analysis with WhyLabs, Evidently, and Great Expectations. Upstream data models are tested with dbt and alerting. A duplicate record may indicate degraded data, while a changing customer or market pattern may be genuine drift. The second problem is harder because the pipeline can remain technically intact while the underlying business changes. COVID-19 is mentioned as an example of a period when many dashboards stopped behaving as expected.
Lineage and registries make both audits and team handoffs easier
Darek Kłeczek recommends adding a small amount of logging to training code so teams can record data and results in Weights & Biases. This creates experiment history and an initial layer of documentation. A model registry adds lifecycle status, such as testing, staging, or production, and records the dataset, compute environment, GPU, and run needed for reproduction. These records help an auditor understand how a model was trained. They also help when an engineer leaves. Instead of reconstructing a project from scattered artefacts, a new engineer can inspect the experiments, data, and model checkpoints. Oliver Chipperfield says his team also stores feature sets and models in Weights & Biases and Azure Blob to preserve lineage.
Business stakeholders should inspect outputs and help explain failures
Michelle Marie Conway separates technical model ownership from business model ownership. Data model owners manage the code, while business owners check outputs, understand how the model is used, and can stop receiving it if it is no longer useful. Her team gives stakeholders access to model versions, data versions, and lineage. Stakeholders have sometimes spotted that a change between releases caused forecasts to shift sharply, which helped the technical team find the problem. Oliver Chipperfield says business users often understand changes in the market better than the data science team. Giving them forecasts alongside other reporting data lets them investigate and build the business explanation.
Explainability should connect model behaviour to the user's decisions
Conway says explainability is more than adding SHAP to a black-box model. Business owners need to understand which data and features drive the output so they can relate it to their subject-matter knowledge and take responsibility for using the model. She explains technical ideas through familiar situations, such as how a customer's behaviour, transactions, products, and interest rates affect a forecast. Oliver Chipperfield prefers reporting the measures that stakeholders actually use, such as forecast accuracy, rather than data science metrics that do not help them make a decision. Mark Huang says LLM teams rely on custom evaluations tied directly to a customer's task, with a result that shows whether the model meets the required benchmark.
"Anything where you can identify who that customer is, especially with someone's bank accounts, like their age, their date of birth, their location, like their postcode, or even more sensitive medical stuff, all comes into play."Michelle Marie Conway10:45
Who should watch
You run machine learning models that influence lending, customer finances, reporting, or other decisions subject to review.
Your team needs a practical approach to model lineage, experiment history, risk-based governance, or handoffs when engineers leave.
You are introducing LLMs into a regulated organisation and need to think through private deployment, evaluations, explainability, and human approval.
