Your data pipeline was built by data engineers.
You data engineers are excellent an answering your question: “is this data correct?”
Enter security. Who ask a different kind of question, they ask you: “who could have changed this, and would we know?”
Taken on their own, each of those two question sets can produce completely different architectures.
And if you’re like most Australian enterprises, chances are, that your AI data pipelines has been designed to answer the first one, until now.
Let’s fix that.
We’ll walk the AI data pipeline end to end, in 7 stages. In doing so we’ll focus on making sure you’ve covered how to answer both those of 2 questions for each stage.
1. Ingestion
Where data enters. Internal systems, third-party feeds, purchased datasets, scraped web content, customer submissions.
Data engineering asks: did it arrive complete, on schedule, in the expected schema?
Security asks: what’s the provenance of every source in this list, and which of them can a stranger contribute to?
That second question tends to not have a clear answer. Because “scraped web content” and “customer submissions” both mean a stranger can contribute to this, and its unlikely that sources were classified this way.
2. Validation and cleaning
Deduplication, null handling, format normalisation, outlier removal.
Note a thing about outlier removal though. It’s tuned to catch data that looks wrong.
But a poisoned record doesn’t look wrong. It looks completely fine. That’s the nature of the exploit.
So your cleaning stage – which feels like a security control (and gets described as one in architecture reviews) – likely provides little protection against a deliberate attacker. It protects you against a broken upstream system. Which is a different threat, entirely.
3. Transformation
Joins, enrichment, aggregation, derivation of new fields.
This is where classification gets lost.
You take three datasets, two of which are internal-use-only, join them, and produce a fourth thing that inherits… whatever label the pipeline was configured to apply. Which is often the label of the first input, or no label at all.
What should you do here?
First, ask your data team what classification the output of your main transformation job carries.
Second, ask them what the inputs carry.
If those two answers don’t match, that’s a control that has stopped functioning.
4. Labelling and annotation
Human or model-assisted labelling of training data.
Often outsourced. Frequently offshore. Occasionally to a vendor whose subcontractors you’ve never enumerated.
An attacker who can influence labels doesn’t need to touch a single byte of your source data. They just need to change what it means.
5. Storage
Data lakes, warehouses, object stores, the staging buckets that were meant to be temporary a couple of years ago.
This one your security team likely knows about well….
Encryption, access control, retention. This is right up security’s alley so your best-covered stage in the pipeline.
Though I’d still ask who has write access to training data, as distinct from read. Because while read access is what everyone usually reviews, write access is what actually matters in this case.
6. Feature and vector stores
Embeddings, feature tables, the vector database backing your RAG deployment.
New asset class. Rarely in the CMDB. Usually stood up by whoever built the AI feature, sometimes on a corporate card.
And an embedding is a derived artifact of your source data – which means it inherits the source’s sensitivity, but almost never inherits the source’s classification label or access controls.
7. Serving and retrieval
The live path. Where the model gets its context at inference time.
And this is the stage that breaks the traditional mental model completely.
The pipeline doesn’t stop any more
Classic thinking goes: you build a dataset, you train a model, training ends, the model ships. Pipeline security is therefore a build-time concern. Batch process. Point-in-time control.
Retrieval-Augmented Generation (RAG) demolished that.
With retrieval-augmented generation, your data pipeline is a runtime dependency. The model reads from your document store, your knowledge base, your ticketing system – live, at inference time, every single request.
Which means that document somebody added to the SharePoint site this morning is now part of your model’s effective input.
Yes that’s right. I didn’t say next quarter, when you retrain. I said this morning.
So every control you designed as a build-time gate – dataset review, approval before training, sign-off on data sources – sits upstream of a pipeline that no longer has a build phase in the place you thought it did.
Your secure reframe going forward
Stop thinking of the AI data pipeline as a supply chain that ends at training.
Think of it as a supply chain with two ends. One ends at training and behaves like a build process. The other never ends at all, and behaves like production.
Your existing controls cover the first one reasonably well.
The second one – the live retrieval path from your document stores into a model that acts on what it reads – is running in most organisations I’ve seen with insufficient access controls and assurance.
Stay tuned for tomorrow: what it actually takes to poison one of these. The number is a lot smaller than most people assume, and there’s a 2025 study that reset the whole conversation.