On AI, changing data pipelines, and why easier access to data makes understanding its provenance more important rather than less.
One of the more interesting changes in AI is happening around data rather than models. The conversation still tends to focus on what a new model can generate, how well it reasons, or which benchmark it has improved, but a quieter change is taking place in the way we reach data in the first place. AI systems are increasingly positioned between the analyst and the sources such as separate tools, interfaces, scripts, downloads, and preparation steps.
This is becoming visible across several parts of the data ecosystem. Conversational analysis environments can already inspect uploaded datasets, write and execute code, produce tables and visualisations, and help investigate unexpected results. Connections with spreadsheets and other working environments are bringing similar interactions closer to everyday analytical tools. Microsoft, for example, now allows users to question and analyse workbook data in natural language through Copilot in Excel, while specialist data providers such as Bloomberg are introducing generative-AI interfaces that allow users to move from natural-language questions towards relevant data fields and products.
Microsoft — Get data insights with Copilot in Excel
Microsoft — Use data from the web and internal sources with Copilot in Excel
These developments may look like improvements to individual tools, but taken together they point towards a more substantial change in the architecture of the data pipeline.
A conventional analytical pipeline makes many of its transitions explicit. We identify a source, retrieve data, inspect its structure, clean it, transform variables, join tables, construct analytical measures, run models, validate results, and eventually communicate what we have found. R and Python made much of this process programmable and reproducible, which was already an important change from workflows dominated by manual spreadsheet operations.
AI introduces another layer because it can operates across several stages at once, compressing sources, retrieval information, preparation and analysis tasks, and finally interpretation into a conversational interaction.
That compression is useful, but it changes what remains visible to the analyst. When I write an R pipeline, I can inspect where the data entered the workflow, which variables were selected, how missing observations were treated, which transformations were applied, and what object was eventually passed to a model. The code may contain mistakes, but the sequence exists as an inspectable analytical object.
When an AI system performs several of these operations in response to a request, the final result may hide much of the analytical path between the original data and the answer. This distinction becomes particularly important when the data carry definitions that cannot be inferred from their values alone.
A mortality series, for example, is not simply a column containing deaths.
Its interpretation depends on the population covered, age structure, cause definition, coding system, reference period, revisions, and whether the measure represents counts, crude rates, age-standardised rates, or modelled estimates.
Claims experience similarly depends on exposure, policy definitions, reporting delays, development assumptions, exclusions, and portfolio composition. An actuarial assumption may appear as a number in a model while carrying an entire chain of judgement about the population and experience from which it was derived.
A conversational system may be able to locate a mortality rate or financial series almost instantly, but analytical work still requires knowing which source produced it, which version was retrieved, what population it describes, how it was transformed, and whether subsequent revisions would produce the same result. These questions are familiar from reproducible research, yet conversational access changes their operational importance because some of the steps where we previously encountered this information may disappear from view.
There is an interesting paradox here. We have spent years improving data pipelines partly by removing friction. APIs replaced repeated manual downloads, packages simplified access to complex databases, reusable functions reduced repetitive transformations, and workflow tools made analytical processes easier to execute consistently. AI continues that trajectory, but at a different scale.
Some of the cognitive work involved in discovering a dataset, understanding its structure, writing the query, and constructing the transformation can now also be delegated.
Removing that work does not necessarily remove the knowledge required to evaluate it. In fact, the opposite may happen. If retrieving and analysing data becomes substantially easier, more analytical effort may need to move towards determining whether the data and transformations are appropriate. Knowing how to obtain a dataset becomes less distinctive when a system can retrieve it for us; knowing what the dataset represents, where its limitations begin, and whether it can support the inference being made becomes more important.
This has consequences for reproducibility as well. Reproducibility has traditionally been associated with preserving code, environments, data versions, parameters, and documentation so that an analysis can be reconstructed.
A conversational pipeline adds another object that may need to be preserved: the interaction that caused the analytical system to make particular decisions.
A prompt saying “compare mortality trends across these countries” is not equivalent to documenting how countries were selected, which mortality measure was used, whether rates were standardised, how missing years were treated, or which source revisions were retrieved. If those decisions are made during the interaction, they become part of the analytical record.
The same issue appears when AI generates code. Generated R or Python can be perfectly readable and reproducible once it enters a conventional project, but reproducibility depends on what happens after generation.
The code needs to be retained, inspected, tested, and connected explicitly to its inputs and outputs.
Otherwise the convenience of producing code can create an analytical process that is easy to repeat interactively but difficult to reconstruct independently. The important distinction is therefore not between AI and traditional programming, but between workflows whose transformations remain observable and workflows in which important decisions become transient.
For teaching, this changes where some of the emphasis may need to sit. Learning syntax remains useful because it provides a way to inspect and control analytical operations, but syntax alone becomes a weaker definition of analytical competence when systems can produce substantial amounts of working code. Students increasingly need to understand why a transformation is being performed, how to recognise an inappropriate denominator, what makes two datasets incomparable, how uncertainty propagates through an analysis, and which information must be retained for somebody else to reproduce the result. These were always important skills; AI is making their relative importance more visible.
Actuarial science provides a useful example because the discipline has always distinguished calculation from judgement. Producing a projection is only one part of actuarial work. The assumptions underlying the projection, the experience used to calibrate them, the appropriateness of the model, the treatment of uncertainty, and the ability to explain the resulting decision are equally important. AI can accelerate the mechanics of constructing and interrogating models, but it does not eliminate the need to establish why a particular dataset, assumption, or transformation is defensible.
What seems to be emerging, then, is not simply a faster version of the existing data pipeline. The boundaries between discovery, retrieval, preparation, analysis, and interpretation are becoming less rigid because a conversational system can move across them on our behalf. That may eventually change the tools we use, the way analytical projects are documented, and even what we consider to be the primary artefact of an analysis. Code may remain central, but provenance, interaction history, data lineage, model assumptions, and validation evidence may need to become equally explicit components of the workflow.
I find this more consequential than many of the incremental improvements in model performance that dominate AI news. A better benchmark tells us something about a model. A changing relationship between people, analytical systems, and data tells us something about how knowledge itself will be produced. As the interface becomes simpler, the underlying chain of evidence does not become simpler with it; instead, understanding that chain becomes one of the central analytical responsibilities.
The data may become conversational. The responsibility for understanding it remains analytical.
A Working Position
My current position is that AI should not be understood as another tool added to the end of the analytical pipeline. It is beginning to operate across the pipeline itself, connecting data discovery, retrieval, transformation, analysis, code generation, interpretation, and communication. This makes the workflow potentially faster and more accessible, but it also changes where analytical responsibility sits. When several operations are compressed into a conversational interaction, the analyst needs stronger mechanisms for recovering what happened between the original question and the resulting number, model, or visualisation.
For that reason, I am becoming less interested in whether an AI system can produce an analysis and more interested in whether the analysis can be inspected afterwards. I want to know which data were retrieved, from which source and version, what transformations were applied, which assumptions entered the process, what code was executed, and whether another analyst could reconstruct the result without depending on the original conversation. In this sense, provenance and reproducibility are not constraints placed around AI; they are part of the infrastructure required to make AI-generated analytical work usable.
This also changes how I think about the future data pipeline. The pipeline may become less visible as an ordered sequence of manual operations, but its underlying structure cannot disappear. Data still move through definitions, selections, transformations, assumptions, models, and interpretations before becoming evidence. AI can make those transitions easier to execute, but the more seamlessly they occur, the more deliberately we may need to preserve them. The emerging problem is therefore not simply how to put AI into a data pipeline, but how to design a pipeline in which AI can operate without making the analytical reasoning disappear.