AI in the data path without breaking ingestion
To put a model in the data path without breaking ingestion, ingestion must not depend on the AI. In NovaeOps, the verdict travels inside the reading, but if the AI is unavailable, the reading is stored anyway. And every verdict warns you when the data is outside what the model knows.
Why put AI in ingestion rather than in tomorrow’s report?
A model that analyses yesterday’s data tells you what went wrong yesterday. If the verdict arrives with the reading, the decision can arrive at the same time as the data, and your team looks at what’s out of the ordinary while it still matters.
Having data is no longer the problem. In water, for instance, Spain’s water digitalisation programme (PERTE) put €170 million into 375 irrigation community projects, 60% of it for remote control and monitoring (MITECO, November 2025). Meanwhile, 14.6% of the water supplied in Spain is lost to leaks (INE, July 2026).
The sensors are installed. What’s missing is people to look at every reading. A verdict on the reading itself does that first pass: the normal goes on its way, and whatever falls outside the normal arrives flagged, with how far to trust the flag.
But putting a model into ingestion comes with risks, and it’s worth knowing them before you do it.
What goes wrong when you drop a model into ingestion carelessly?
Here are five failures worth planning for, and what NovaeOps, our AIoT platform, does about each one:
| Risk | What happens | What NovaeOps does |
|---|---|---|
| The AI goes down and blocks ingestion | You lose readings exactly when something is wrong. | The reading is stored anyway; the verdict is an extra. |
| Data drifts outside what’s known and nobody notices | The model answers confidently about something it has never seen. | Every verdict carries an out-of-distribution warning. |
| Running a model on every reading costs money | You pay to keep the model running, whether it helps or not. | You choose which collections get a verdict and pay per delivered verdict. |
| The trained model isn’t the one answering | Answers differ from the validated ones, with no visible error. | The service reproduces what was measured at training time before it is published. |
| A retrain quietly degrades production | The new model is worse and nobody compared it. | The candidate is compared with the one in production before promotion. |
How does NovaeOps handle each of those risks?
If the AI isn’t there, the reading is stored anyway
In NovaeOps, ingestion comes first. The verdict is written into the readings of the collections you choose, but it’s an extra, not a prerequisite: if the model restarts, is being updated or fails, the reading still goes in.
It sounds obvious, but it’s one of the decisions that gets skipped when a system is designed in a hurry. A history with gaps at exactly the moments when something was going wrong can’t be recovered.
A warning when the data is outside what the model knows
A model trained on summer data watches winter arrive. You install a sensor from another manufacturer with a different range. Someone recalibrates a meter. The model keeps answering, just as confidently, about something it has never seen.
That’s why every verdict carries an out-of-distribution warning. Because it is written into the reading itself, your history tells you when your data started to leave familiar ground. It’s a good signal for deciding when to retrain.
You pay per delivered verdict, not for a model sitting idle
Not every collection needs AI. You choose which ones get a verdict written into their readings. And AI is billed per delivered verdict: an idle model costs nothing. There are no per-device or per-user fees either.
From history to model, without moving the data
NovaeOps freezes your history to Parquet, brings it back when you need it and trains models on it without leaving the platform. Your data doesn’t travel to another system to be trained on. And if you ever leave, you export it to Parquet, CSV or JSON.
What was trained is what answers
The verdict comes from CogniX, our predictive AI engine, built into the platform. Every training run records its expected answers, and the production service has to reproduce them before it is published. That rules out one of the quietest failures there is: preparing data one way for training and another way for serving.
No retrain goes live without a comparison
Retraining is triggered by a person, a schedule or NovaeOps itself. The new model goes in without stopping the service, but before you promote it, you compare it with the one in production. A newer model is not, by definition, a better one.
Why not put a language model on every reading?
Because a language model takes seconds and burns CPU on every reading. If you receive thousands of readings a minute, the numbers don’t add up, in time or in money. And ingestion can’t sit waiting for a model to finish reasoning.
The split that works is a different one:
- In the data path, a predictive model that answers in milliseconds, with the decision, how far to trust it, an unknown-data warning and which variables weighed in.
- On top, the language model, over MCP. Your assistant asks why a reading was flagged and explains it to you in plain words.
NovaeOps exposes more than 180 operations over MCP, so your assistant can monitor and run the platform. Operations that delete anything ask for explicit confirmation.
Who decides what happens with the verdict?
You do. The AI verdict informs; you decide with rules what triggers an automatic action. NovaeOps rules work with hysteresis, so a bouncing signal doesn’t fire the same alarm over and over again.
That split matters. The AI flags, quantifies and explains; the action is decided by a rule you wrote or by a person who reviews it. Why every verdict has to tell you how far to trust it is the subject of accountable AI.
How do you start a pilot with AI in ingestion?
With a closed scope and success criteria agreed before you begin. An order that works:
- Pick one collection and one question: which readings fall outside the normal, on which devices.
- Train on your history, frozen in Parquet, without taking it out of the platform.
- Turn the verdict on for that collection only and set how you will measure success.
- Watch the unknown-data warnings: they help you decide when to retrain.
- Decide with rules which verdicts trigger an action and which go to review.
- Compare every retrain with the model in production before promoting it.
NovaeOps is available for pilots. It runs in our cloud, on your infrastructure or at the edge, including on modest hardware such as a Raspberry Pi 5, with the same product.
In short
AI in ingestion works if ingestion doesn’t depend on it, if every verdict warns you when the data is unfamiliar, if you only pay for what you use and if no model reaches production without being compared first. If you have equipment in the field and want to see what its readings are telling you, see how NovaeOps works.