Earlier this year, at We.Publish — a Swiss non-profit running open-source publishing infrastructure for independent media — we migrated off Google Cloud to self-hosted infrastructure. We reduced costs by roughly a factor of 10 — but more importantly, we regained control.
Now we’re facing a different question: which AI components do we actually want to integrate into a system that runs production workloads for 20+ media organizations?
This is not a general take on AI. It’s how I currently think about it after building and evaluating AI features in real systems.
1. Productivity: clear wins
Some AI use cases are straightforward.
At We.Publish, we tested Whisper for generating audio from articles — essentially turning written content into something you can listen to. The integration is technically simple, the value is direct, and we evaluate it as an optional accessibility feature for publishers who want broader reach.
Technically, this is not very controversial:
- it doesn’t change authorship
- it doesn’t replace journalists
- it makes content more accessible
This is the category where AI feels like infrastructure: clear benefit, low risk, easy to explain. Most of the time, these are easy decisions.
Another ongoing experiment: automated conversion of design files (Figma and similar) into front-end code. The goal is to make redesigns affordable for independent media outlets that typically can’t budget for full custom design-to-development cycles. It’s still experimental, but the principle is the same — AI removing tedious work rather than replacing meaningful judgment.
2. Dual-use systems: where it gets uncomfortable
Things get more complicated with systems that understand and structure data.
In security and legal-tech projects at Seccom, we’ve worked with open-source models to vectorize documents — making large collections searchable and semantically accessible. This is extremely useful: faster access to information, better internal workflows, less manual work.
But it also changes what becomes possible. Once everything is structured and searchable, you can assist decision-making — and you can also monitor behavior, patterns, and communication at scale.
The same capability enables both. The difference is not technical — it’s in how the system is designed and used:
- what data is included
- what is logged
- who gets access
- what becomes automated
This is where AI stops being a tool and becomes part of a control system.
3. Generative media: replacing output
This is the category I’m most skeptical about.
In a CMS, it’s tempting to integrate AI-generated images, automated summaries, even fully generated articles. We’ve deliberately not pushed in that direction. We’ve turned down requests to ship AI-generated lead images and auto-generated article summaries — for independent media, where attribution and editorial control are part of the trust equation, those aren’t features. They’re problems.
The reason is simple: these systems don’t optimize a workflow — they replace the output. That creates very different dynamics:
- authorship becomes unclear
- trust becomes harder to maintain
- incentives shift toward volume over quality
And unlike productivity tools, this scales almost without cost. For independent media, that’s not a neutral change.
There are exceptions where generative AI works — when the design forces verification into the loop. One example we’re piloting with Bajour, a publisher on our platform: their “Dorfkönig” project automatically gathers information about a Swiss municipality, validates it via WhatsApp conversations with people who actually know what’s happening in that village, and only then generates a targeted daily newsletter for residents.
The generation step is AI. The verification step is human. Without the second step, this would be exactly the kind of system I described above. With it, it becomes something else: AI as scaffolding for human knowledge, not a replacement for it.
4. Knowledge systems: powerful, but easy to overtrust
Another category I find increasingly relevant is AI as a knowledge interface. Using embeddings and vector search, you can query large document sets, surface relevant context, and assist complex workflows. In practice, this is incredibly powerful.
But there’s a subtle shift: the system doesn’t just give access to information — it shapes how decisions are made.
The risk is not just hallucination. It’s overconfidence. When answers come back fast, well-formulated, and without visible uncertainty, it becomes very easy to trust them more than you should.
We’re currently building exactly this kind of system at We.Publish — an MCP-based assistant integrated into the CMS that lets customers (newsroom editors, ops people) query the platform faster. The principle is explicit: it accelerates answers, but it never replaces human contact. If a customer needs a real conversation with our team, the bot points them there. The system is for friction reduction, not relationship replacement.
What we underestimated: the integration itself wasn’t the hard part — wiring MCP into the CMS was straightforward. The harder problem turned out to be earlier in the stack. The customer-facing data the assistant draws on isn’t yet structured cleanly enough to give reliable answers. We’re now investing in the data foundation before expanding the bot’s reach. An MCP integration is only as good as the data underneath — and that’s not something more AI can fix.
What actually matters
One sentence captures it for me:
AI questions are infrastructure questions in disguise.
The model is rarely the problem. The system around it is.
Every AI feature forces the same questions:
- Where does it run?
- Who controls it?
- What data does it see?
- What happens when it’s wrong?
- Who is accountable?
After moving infrastructure in-house, these questions stopped being abstract. You can’t outsource them anymore.
How I currently decide
When we evaluate AI features, I’ve started using a simple filter:
- Does it reduce friction without shifting control?
- Does it introduce capabilities that can be abused at scale?
- Does it replace human output or support it?
- Can I explain its behavior and failure modes clearly?
If I can’t answer the last question, we usually don’t ship it.