Insights
Page 2 of 6
Automating insurance claims with AI: what applies on 2 August and what was postponed to 2027
Regulation (EU) 2026/1744 was published in the Official Journal on 24 July 2026 and has been in force since the 27th: the obligations for Annex III high-risk systems are postponed to 2 December 2027, and those for Annex I to 2 August 2028. But the transparency duties of Article 50 were not postponed and apply from 2 August 2026 —with the marking of synthetic content enforceable from December for generative systems already on the market—, so if an assistant opens the claim or drafts the communication to the policyholder, that affects you now. This piece breaks down the six phases of a claim and where AI fits without risk, the delimitation of Annex III 5(c) (pricing in life and health, not claims handling; non-life outside), the three reasons claims pilots never reach production —inaccessible policy wordings, zero traceability, the human in the wrong place— and a seven-step path to start with one narrow claim type with your context in order.
How to write the technical proposal of a public-sector tender
Writing the technical proposal of a public-sector tender isn't describing your company: it's responding, point by point, to a tender document that has already told you how it's going to score you. This article walks through the method —read the tender document backwards, starting with the award criteria, and build the outline around them with length proportional to the points—, the error that disqualifies with no remedy (mixing economic information, or information scorable by formula, into the technical envelope), and the backing rule: if a claim can't point to a company document that sustains it, either it becomes one that can, or it goes. And then the structural problem no writing tip solves: a company that bids regularly has already written almost everything it needs, but it lives scattered, so every tender starts near zero and the real decision ends up being which of the three to bid on. Plus the invisible cost of outsourcing (the knowledge leaves with the third party) and where AI fits and where it doesn't: it speeds up locating, selecting and adapting your own material while citing the source; it doesn't win the tender, doesn't replace human review and doesn't invent what you don't have.
Shadow AI: the AI your teams already use without control (and how to govern it)
Shadow AI is the use of AI tools inside your company without the approval or control of the technology function: the successor to "shadow IT", with the aggravating factor that AI swallows data. When you run the inventory at a mid-sized company, the number surprises you: dozens of tools in use today —individual ChatGPT, copilots with no policy, AI in the CRM or email— with no audit. This article breaks down what it is and why almost every company has it, the real risk you don't see in any budget (data leakage, compliance/AI Act, inconsistency, invisible cost, decisions with no trail), why banning it doesn't work (it goes further underground and you switch off a signal of real demand), and how to govern it without killing it: inventory with no witch-hunt, a clear and usable policy, and —the key— a governed corporate AI environment that's better than the individual shortcut, so shadow AI disappears on its own. Buyer CIO/CISO/COO, governance angle.
Automating B2B customer support with AI, without hallucinating to your accounts
Automating B2B customer support with AI is one of the highest-return bets: a large share of tickets are variations of the same questions. But B2B support has a critical difference from consumer support: each customer is an account with a contract, and an invented or generic answer is a crack in a relationship that's expensive to win. This article breaks down why support is the perfect candidate for AI and why it hurts today, why a generic chatbot is dangerous in B2B (it hallucinates answers about your product, doesn't know the account context, escalates poorly to a person, leaves no trail) and what an automation you can put in front of the customer demands: context engineering of your product and policies, verification with limits (say "I don't know" and escalate instead of inventing), clean human escalation with context, and traceability. Starting with assisted deflection and measuring deflection, resolution time and CSAT.
AWS Bedrock vs Azure OpenAI for mid-market: which to choose
If you're comparing AWS Bedrock and Azure OpenAI for your company, this guide gives an honest read on both —what each one fits along the axes that matter in mid-market: model catalog, portability, fit with your cloud, governance and data residency, cost— and then tackles the expensive mistake: believing the platform decision determines the outcome. Choosing a platform is, in effect, choosing which cloud you marry for years, and what weighs most on cost isn't today's rate but the cost of exit. The answer isn't "Bedrock or Azure", it's architecture: choose on real fit but design multi-model from day one, keep your business context out of the vendor and measure cost per useful task. With a declared bias disclosure (onext builds Enterprise AI on Bedrock for its multi-model access) and a portability / no-lock-in thesis.
An AI agent in your SaaS product: build the team or bring in a partner?
Putting an AI agent into your product is the feature every Head of Product has on the 2026 roadmap: a copilot, an agent that runs a workflow. The easy part is showing it works; the hard part —and the one that actually costs money— is deciding how you build and sustain it. This article orders the decision: what an agent in your product is (and why it isn't a chatbot), why the demo deceives (the invisible 80%: reliability with real-world cases, evaluation, cost per task, security, maintenance), and the €50-300k decision between building the team in-house (maximum control but expensive, slow and hard to retain), buying a closed solution (fast but no differentiation) or bringing in a partner who builds and transfers (the speed of buying with the ownership of building). The rule: what differentiates you, build it (with a partner if you don't have the team); what's infrastructure, buy it. Track E, high ticket, buyer Head of Product / product CTO.
Automate accounts payable with AI, without accounting errors
Automating accounts payable with AI is one of the clearest-return bets for a CFO: high volume, highly manual and repetitive (capture the invoice, match it against the purchase order and the receipt, code it, approve it, post it). It's also where an error has a direct consequence: a misread amount gets overpaid, a wrongly assigned account throws off the close, an undetected duplicate is money that goes out twice. This article breaks down why it's an ideal candidate to automate, why generic AI fails in finance (extracts amounts wrong, codes to the wrong account, doesn't detect duplicates, leaves no audit trail), and what a governed automation requires: context of your chart of accounts, vendor master and approval rules; amount verification and three-way match; duplicate and anomaly detection; audit traceability; integration with your ERP and a human on the exceptions. The financial process of onext Enterprise AI's document-automation cluster.
Responding to RFPs with AI: from weeks per proposal to a governed response
Automating RFP response with AI is tempting: responding to a request for proposal is expensive, slow and repetitive, and much of it you already wrote in previous proposals. But it's the process where doing it by eye hurts most: in an offer an error is negotiated; in an RFP, a requirement you miss leaves you out before anyone reads your proposal. This article breaks down why responding to RFPs is so expensive (requirements matrices, deadlines, a corpus of previous answers, multidisciplinary teams), why generic AI is more dangerous here than in an offer (skips requirements → exclusion; hallucinates compliance and certifications → legal risk; cites the wrong specs; answers generically and scores low), and what a governed automation requires: context of your won proposals, coverage verification requirement by requirement, traceability of every claim and the bid team in control. The other side of the document process onext automates in Enterprise AI.
Automating your sales proposals with AI, in a governed way
Automating the generation of sales proposals with AI is one of the highest-immediate-return opportunities in a mid-sized company: it's repetitive, document-intensive and consumes hours of your best people. It's also one of the ones that turn out worst without method. The typical experiment —asking a chatbot to draft the proposal— impresses in the demo and fails in production because the AI doesn't know your business: it invents prices, ignores your discounts, applies terms that don't apply. And in a quote, a wrong price is money or a legal problem. This article breaks down why proposals are the perfect process to automate, why the first attempt with ChatGPT doesn't reach production, and what a governed automation requires: context engineering (catalog, pricing rules, templates), human verification on anything touching price, traceability for finance and legal, integration with CRM/ERP and cost per quote measured. With proposal generation as one of the processes onext automates inside Enterprise AI.
Claude vs Cursor vs Copilot for enterprises: which to choose
Your team is asking for (or already using) Claude, Cursor or GitHub Copilot, and it's time to decide which one to standardize on and how much to budget. This guide gives an honest read on all three —where each one shines and which situation it fits, along the axes a CTO cares about (integration, enterprise governance, agentic work, cost model, adoption curve)— and then tackles the expensive mistake: believing the tool decision determines the return. It doesn't. The same license produces ×3 or ×0 depending on how people work. The 80% that decides the ROI is the method —specification (SDD), context engineering and human verification— your team uses to turn any of the three into measurable throughput. With a declared bias disclosure (onext works on Claude) and a tool-agnostic thesis.
AI for healthtech: your health product's AI, to production
Personalizing each user's plan, an assistant that answers questions, tailored content: AI promises a lot in a health or wellness product, and the demo comes out fine in an afternoon. The hard part comes after: making it work with thousands of real users, over personal health data, without an AI team on staff. That leap is where almost every health product stalls, and it's not because of the model. This article breaks down why a health product's AI stays in the demo (generic personalization, sensitive and regulated data, no in-house AI team), what production really requires (context engineering, verification and safety limits, privacy by design, cost per useful interaction) and how to take that step through concrete use cases with a partner that builds the product end-to-end. With the Hacktua case as proof —and an honest note: B2C wellness, not a clinical system.
AI for insurers: why the pilots don't reach production
Mid-market insurers fill up with AI pilots that impress in the demo and stall before production. A vendor shows AI reading a claim report or classifying an underwriting risk in seconds; six months later, it's still a pilot. It's not a model problem: it's context (the AI doesn't know your lines, rules or terms), a reproducible quality criterion (without evals, every release is a bet on premiums and payouts) and traceability and cost (without decision logging or cost per case, compliance blocks the deployment and the business case dilutes). This article breaks down the three processes where insurance AI promises the most and stalls the most —claims, underwriting, document/RFP response—, what production really requires in a regulated sector (context, verification, AI Act, measured cost) and how to start with one concrete process instead of a grand project that promises everything.
How to know if your product's AI works: evals and cost
"It seems to work" isn't a metric: it's an impression, and with generative AI impressions deceive. To take an AI feature of your SaaS product to production and keep it profitable you need to measure two things, and only two: verified quality (reproducible evals that tell you whether the output is correct, not whether it sounds good) and cost per useful task (credits consumed divided by outputs that passed the eval and were actually used). This article is the practical guide: how to build evals that actually help, by levels; how to calculate cost per useful task with a numeric example; what minimum dashboard to check every week; when an AI feature deserves to stay alive; and the mistakes that break your measurement. Without this, every release is a bet and every invoice a surprise.
Integrating AI into your SaaS product without mortgaging the roadmap
Putting AI into your SaaS product —RAG, agents, LLM features— is easy to start and hard to finish: it works in the demo and breaks with real-world cases, because it doesn't know your product and has no reproducible quality criterion, and the cost spikes without anyone knowing how much it will cost to maintain. The problem isn't the model: it's that production demands consistency, governance and scale, and only context engineering delivers that (capturing how your product works and turning it into the context the AI uses) with human verification at every step and cost per useful task measured from day one. How to do it without mortgaging the roadmap: what to build first, how to measure whether it works, and when it's build vs. buy.
Context engineering vs. prompt engineering
If your team has spent months fine-tuning prompts for ChatGPT, Claude or Copilot, gets brilliant demos and yet nothing reaches production reliably, it's not the tool or the model: it's that there are two different disciplines behind "working with AI" and confusing them leaves you stuck on the one with a ceiling. Prompt engineering fine-tunes the instruction of a single interaction: it doesn't accumulate, it lives in the head of whoever writes it and it depends on whichever model is current. Context engineering builds what the model knows about your business —rules, criteria, domain— as a reusable asset, yours, that survives model changes. The prompt is how you ask; the context is what the model knows about you when you ask. Why that distinction decides whether AI reaches production.