TL;DR: AI has made building integrations cheap. It has not made them trustworthy. When writing a route takes minutes instead of an hour, the expensive work is no longer the building but the verifying — confirming that the result does what it is supposed to do — and that work happens through the management surface. Which is why the product decision we have spent the most time on at Fasthub isn't about the model. It's about what the screen does when it doesn't know. A green light that means nothing is the most expensive thing an integration platform can display: it doesn't remove the risk, it defers the bill and grows it on the way.
Through the spring and summer we have written about what the integration layer means for everything around it: for sovereignty, for compliance, for procurement. This is the first article in which we write about what we built ourselves — and we start where that story rarely starts. Not with generation. With what the screen says afterwards.
When building gets cheap, the bottleneck moves to verification
Fasthub came out of something we noticed in our own delivery work: AI-assisted development compressed a quarter's worth of Apache Camel and Kubernetes work into weeks. The clients were happy. The margins weren't. That tension is what forced us to build a product.
But one thing didn't compress at all, and it's the part that matters here. Building got faster. Verifying didn't.
In the old model, expertise was a scarce resource — and it doubled as invisible quality assurance. The same person who wrote the route usually also knew what it does at two in the morning, what happens when the other end stops answering, and which part breaks first when volume goes up tenfold. None of that lived in a document. It lived in the person who built it.
When generation gets cheap, that quiet control disappears. It doesn't move into the model. It moves into the surface a human looks at the result through. An integration you build in an hour but only trust two weeks later is a two-week integration.
This is where the real work of an AI-native platform gets done — and it's duller than the demos suggest.
Silent green is the most expensive failure mode
Software fails in two ways. It can tell you it broke, or it can look like nothing is wrong. The second is considerably more expensive, and the second is also the one an interface picks by default, because an empty state always looks calmer than an explanation.
We wrote one rule into Fasthub that repeats throughout the product: when the system doesn't know, it says so.
In practice that means things which look like minor details taken one at a time:
When a cluster has no metrics-server, resource usage is not displayed as zero — it is hidden and the missing component is raised. Zero would have been an answer. It would just have been the wrong one.
When an alert rule's query is broad enough that Loki rejects it, the rule doesn't show up green. It gets a state of its own, one that says it isn't being evaluated and isn't monitoring anything. A rule with no delivery target at all is flagged for the same reason: it fires into the portal and notifies nobody.
When a table is truncated, it says its values may not cover the whole time window — rather than presenting a partial answer as a complete one. When the execution view paints a run that happened while message body capture was switched off, it says so, instead of showing empty values as real ones.
When an integration has never had a pricing snapshot recorded, it doesn't appear in billing as a tidy zero row. It appears as a warning.
Not one of these is a feature anybody would ask for in an RFP. Together they are the same decision made hundreds of times, and that decision is the foundation of the whole product's trustworthiness. Showing a zero is always easier than explaining why there is no number.
A false green doesn't disappear. It becomes somebody else's bill.
So far this has been product philosophy. The next part is economics.
Hidden uncertainty doesn't remove risk. It moves it later — and the same defect costs a different amount depending on when it surfaces. During the build it costs minutes. In production it's an incident. In an audit it's a finding. An interface that shows green without knowing is, in effect, a decision to pay for it at the most expensive possible moment.
A monitoring rule that doesn't actually monitor anything isn't worth zero. It's worth a negative amount, because it produces a false sense of safety — and the price lands at the first outage nobody noticed, because an alert had been set up.
A metric that reads zero because no number exists is a budgeting error waiting its turn. Nobody questions a tidy figure.
And a dangerous operation offered as a button, without its consequence written out, isn't a feature but a training problem — which is to say, a dependency on whoever happens to be on shift. For an irreversible operation, the right product decision isn't the easiest possible button. It's a button that states its consequence before it is pressed — and sometimes a deliberate decision not to build the button at all, and to explain why on the spot instead.
One concrete recommendation follows from this, and it isn't about us. When you evaluate any integration platform, ask them during the demo to cut the connection to a backend system, and watch what the screen does. It's the cheapest way to tell a real management surface from dashboard theatre, and it takes two minutes.
When AI writes, accountability doesn't disappear — it has to be placed somewhere
We have written before that the real change in the integration business isn't speed but who is accountable when things break. When AI writes the change, the question doesn't go away. It simply moves to a place where few platforms are willing to address it out loud.
Accountability isn't a property of the model. It is three product decisions that every platform makes on your behalf — whether it tells you about them or not.
Where is the approval gate? The tempting answer is "everywhere": every change the AI makes goes to a human for approval. It is also the wrong answer. A gate in the middle costs exactly the speed the AI was acquired for, and returns no certainty in exchange — by the tenth diff nobody is reading any more, they're approving. In Fasthub the gates sit at the ends, where the decisions actually get made. Before implementation, a human approves the plan, and it cannot be approved while a blocking question or decision is still open — and the AI never writes the answer to an open question itself. Same principle as above: an unset usage parameter produces an open question in the plan, not a guess. At the other end, deploying to a profile always requires a deliberate human choice; the AI can prepare it, but a human gives the approval, every time. The writing work in between travels as git commits, and can be reviewed either change by change or afterwards as a whole. That is a speed choice, not an accountability choice.
Who can change the limits? The AI's writes are bounded by per-integration compliance settings. A human defines them and can also change them, and the change is recorded in the audit log. The AI cannot. That difference is the entire definition of a control: a constraint the governed party can loosen itself whenever it gets in the way isn't a control, it's a recommendation.
Does the decision leave a trace? Who approved the plan, what changed during implementation, who pressed deploy and which version it landed on. This is the question an auditor asks — and one that either has an answer by default or has none at all, because it doesn't get built after the fact.
As of 2 August, the AI Act's provisions on general-purpose AI are in their enforcement phase, and that turns these three choices into questions you will have to answer to somebody other than yourself. We are not claiming that we have safe AI. We are claiming that every platform has already made these three choices for you, and that you have a right to know what it chose.
Why this is a sovereignty question, not a usability question
In July we wrote that the Commission's cloud sovereignty framework made sovereignty measurable — and that the scorecard typically has no row for the integration layer. This is the continuation of that.
Supply chain transparency isn't only a question of where the code comes from. It is also a question of whether the system tells you the truth about its own state. A platform that hides its own uncertainty is unauditable regardless of where its data centres sit and whose flag flies on its website. Open source gives you the ability to read what the system does. An honest management surface is the part that tells you what it is doing right now.
We are not neutral here. Fasthub is built in Turku, entirely from open source technologies and hosted 100% in the EU, and this article describes a design principle we chose deliberately — one whose price is that our product occasionally looks less certain than a competitor that doesn't tell you.
It is a trade we would make again. A green light is worth earning, not setting as the default.
Fasthub is an AI-native integration platform built in Turku, Finland — entirely from open source technologies and hosted 100% in the EU.