Category: AI Portfolio

  • Build or Rebuild? What planning my first App Store product taught me about the decisions you cannot undo

    Three weeks of research before a single line of code — and why the most expensive mistakes in a venture are made in the first architecture conversation, not the last sprint.

    The setup

    For the past few weeks I have been planning Tendrilo, my first product intended for the App Store. The idea is simple enough to explain in one sentence: it shows you the people who matter across work, family and hobbies, remembers when and what you last spoke about, and tells you when a connection is slipping — with a concrete reason to reach out.

    The concept was finished. The brand was finished. The logo, the colour system, the typography, the interaction prototype — all done. What I had not done was write a single line of code.

    That turned out to be the most valuable thing about the project so far. Because the research phase killed roughly a third of my product, changed my cost base by a factor of five, and taught me that the questions I was asking were the wrong ones.

    The first surprise: half the product was impossible

    Tendrilo’s premise depends on knowing when you last spoke to someone. The obvious source is WhatsApp. Everyone uses it, the data is right there on the phone, and the feature practically designs itself.

    It cannot be done. On iOS there is no API, no shared container, no notification access. On Android there is a technical route through the notification listener, but Google’s policy treats reading messenger content as exactly the kind of thing it rejects. This is not a difficult integration. It is a closed door.

    Instagram was worse, and more instructive. Someone told me that access was possible through a third-party provider using MCP — the protocol everyone is currently excited about. I spent an afternoon establishing whether that was true.

    It is true, in the same way that a lockpick is a key. The Instagram Basic Display API — the only interface that ever allowed a third party to read a personal account — was shut down on 4 December 2024 with no replacement. It took Instagram features out of Tinder, Hinge and Discord on the way. What remains requires a Business or Creator account, and professional Instagram accounts cannot be private.

    So how do those MCP servers work? They take your user’s Instagram username and password and log in with the user’s own credentials against the private mobile API. That is a terms-of-service violation, and the account that gets suspended is your customer’s, not yours.

    This is where I learned something that generalises well beyond apps:

    MCP is a calling convention, not an access grant. It carries no credentials of its own and has no privileged relationship with any platform. If the underlying API does not expose the data, no wrapper around it can. Strip away the MCP layer and you are left with a scraper.

    Spotify and Strava taught the same lesson from a different angle. There the wall is not technical at all — it is contractual. Strava’s API policy, effective 1 June 2026, states plainly that data from one user “may be displayed or disclosed … only to that user” and may not be shown to others “even if such data is publicly viewable.” No quota tier changes that. No consent from the friend changes that.

    Half of what I had drawn on the whiteboard was unbuildable. Not hard. Unbuildable.

    The one decision that changed my costs by a factor of five

    I originally designed Tendrilo to keep everything on the device. Then I decided a cloud version was necessary for sync and reliability. That single change moved me from “barely regulated” to “fully responsible controller under GDPR” — because the app stores notes about roughly eighty people per user, and those people never consented to anything.

    Free-text notes about eighty friends will, over time, reveal health, religion, politics and relationships. Under GDPR that is special category data, and the usual legal basis of legitimate interest is not available for it.

    Then it gets worse in a way I did not see coming. The German supervisory authorities publish a list of processing operations that always require a data protection impact assessment. Entry 9 of the list for the private sector reads: the creation of comprehensive profiles about the interests, the network of personal relationships or the personality of data subjects. I did not have to argue my way into that entry. It is a one-line description of my product.

    And any processing that requires an impact assessment triggers, under § 38(1) sentence 2 of the German Federal Data Protection Act, a mandatory data protection officer irrespective of headcount. The twenty-employee threshold most founders have heard of is in sentence 1, and it does not apply here. Being Swiss does not get me out of it: § 1(4) no. 3 extends that Act to controllers with no establishment in the EU who fall within the GDPR’s scope. My own Swiss law makes the same role voluntary. Same product, same data, different postcode of the customer.

    That chain — a stored relationship graph → mandatory impact assessment → mandatory officer — was going to cost me somewhere between €3,500 and €5,000 in the first year.

    Client-side encryption of the content fields is the highest-leverage change available. Two to three days of extra engineering. The server stores pseudonymous identifiers, timestamps and counts in the clear, so it can still detect that person a7f3 has gone quiet and fire a notification. It simply does not know that a7f3 is Anna.

    I want to be careful here, because this is where I first talked myself into something too good. Encryption removes the special category problem completely, because there is no readable content left to be special. It does not by itself remove entry 9, which describes a data model, not a file format — a graph of relationships with interaction frequencies is still a graph of relationships. What encryption buys is that the threshold assessment can point at a mitigation instead of at a hope. It converts a certainty into a position I have to be able to defend in writing.

    First-year cost if that position holds: €500 to €700. If it does not, add an external officer at roughly €100 to €300 a month.

    And one obligation I could not design away at all: as a Swiss company with no EU establishment serving people in Germany, I need a representative in the Union under Article 27. From about €350 a year, permanently. It is worth sorting your obligations into the ones that are engineering problems and the ones that are simply invoices.

    This is not a privacy story. It is an architecture story. The encryption decision was not made for marketing reasons and it was not made for ethical reasons. It was made because a two-day engineering choice turned a €3,000 recurring obligation from certain into arguable. You only see that if you map the regulatory consequences of your data model before you build it, not after — and you only see the limits of the fix if you then go and read the actual list.

    The pricing trap nobody puts on the landing page

    I am building on Supabase. For a first product it is genuinely excellent: a Postgres database, authentication, file storage and an auto-generated API, connected to Claude Code in about ten minutes, running in a Zurich region, free to start.

    Here is what the pricing page does not make obvious.

    The Pro plan starts at $25 per month. Compute is billed separately, per project, and the $10 of monthly compute credit is granted once per organisation — not per project. So a production project plus a staging project already costs $35 to $40 before you have stored a byte. Point-in-time recovery is $100 per month for seven days of retention — the same capability costs €0.70 at IONOS, €3 at Scaleway, and is included in the tier price at Exoscale. And egress runs at $0.09 per gigabyte beyond the included allowance, which at two terabytes a month is $157 — a line that is effectively zero at providers that include traffic.

    Run the numbers across three stages and the picture is clear:

    UsersSupabaseScaleway managedSelf-hosted
    100~€37€24€20
    2,000~€78€45€27
    20,000~€292€168€71

    At launch scale the difference is noise. At traction scale it is four times.

    The conclusion is not “don’t use Supabase.” It is the opposite. Use it, because time to first working endpoint is the scarcest resource you have. But use it with a rule:

    Keep the schema generic. Plain Postgres, standard SQL, no dependency on vendor-specific edge functions or proprietary abstractions. Treat the convenient platform as a rented starting position, not an address.

    That rule costs nothing while you are small and saves a rewrite when the bill starts to bite. It is the same discipline as not letting your iOS-only decisions calcify when you know Android is coming — a habit, applied early, that turns a future migration from weeks into days.

    The frameworks I should have applied on day one

    Here is my honest confession. I did all of the above — three weeks of API research, regulatory analysis, provider comparison, cost modelling — before I had rigorously answered a much more basic question.

    Who is this for, and what will they pay?

    I had priced Tendrilo at CHF 4.50 per month. The comparable products — Dex, Clay, Covve, Monica — sit between $9 and $12. I was at roughly half the market rate, and I had not thought hard about what that does.

    It does two things. It makes paid acquisition structurally impossible, because the lifetime value cannot carry the ad cost. And it doubles the number of subscribers required for every revenue milestone. The lower bound of the Swiss seed benchmark is around CHF 200,000 in annual recurring revenue. At CHF 4.50, minus the app store’s cut, that is between 4,300 and 5,300 paying subscribers. At CHF 8.90 it is roughly half that.

    There are two frameworks I know from executive education that would have surfaced this on day one, and I did not use either.

    Minimum Viable Segment

    The first is Michael Skok’s Minimum Viable Segment, from the Startup Secrets programme he teaches at Harvard. The definition is elegantly brutal:

    Minimum = small enough to dominate. Viable = you can succeed with your MVP.

    You find your segment where five circles overlap: pain points, customer profile, product use case, channel, and — the one I skipped — budget.

    Five overlapping circles: pain points, customer profile, product use case, channel and budget, meeting in a central cluster of demand
    Michael Skok’s Minimum Viable Segment. The fifth circle — budget — is the one most product people wave at.

    Budget is not a pricing question. It is a segmentation question. How much will these specific people spend to solve this specific problem? If you cannot answer that before you build, your price is a guess dressed as a decision. And a wrong price is not a marketing problem you can fix later; it determines whether paid acquisition, investment and even your own salary are arithmetically possible.

    Notice also that four of the five circles were things I had genuinely thought about. Channel and budget were the two I had waved at. That is not a coincidence — engineers and product people converge naturally on pain, profile and use case, because those are the fun ones.

    The Diamond

    The second is the business model Diamond, from Thomas Eisenmann’s business model analysis at Harvard Business School. It asks whether a venture can create, deliver, make money, and do so sustainably across four corners:

    Business model diamond with four corners: Customer Value Proposition, Go-to-Market Strategy, Cash Flow Formula and Technology Operating Model
    Thomas Eisenmann’s business model Diamond. I had spent three weeks in a single corner.

    Look at where I had spent three weeks. Entirely in TOM. Which providers, which encryption, which framework, which APIs, which region. Real work, correct answers, and one full corner of a four-corner model.

    My CVP was strong — I could state it in a sentence. My GTM was a vague intention to post somewhere. And my CFF was quietly broken, because CHF 4.50 makes the arithmetic fail no matter how good the other three corners are.

    The diamond’s point is not that you need all four. It is that a weak corner is not a weak corner — it is a broken model. You cannot compensate for an impossible cash flow formula with an excellent operating model. I had been optimising the corner I found most interesting.

    Skok’s related heuristic is worth keeping next to it. He argues the products that spread are the ones that SLIP: Simple to use and install, Low to no initial cost, Instant and ongoing value, Plays well in the ecosystem. Read that list again and notice that three of the four are go-to-market properties expressed as product decisions. The framework refuses to let you separate what you build from how it reaches people.

    Where this is going

    This is the part that has stayed with me longest, and it is why I am writing it down.

    Everything I found in those three weeks was findable. Every API restriction is published. Every regulatory chain is in the legal text. Every pricing trap is on a pricing page. None of it was secret. It was simply distributed across forty sources, in four languages, in documents nobody reads until the problem has already cost them something.

    And the frameworks that would have caught the biggest mistake — the pricing one — are taught at Harvard and MIT and have been in the public domain for years. I knew they existed. I did not apply them, because when you are excited about an idea, you start with the part you enjoy.

    So the natural next step, for me, is a platform where an idea gets challenged against predefined criteria before the work starts. Not a business plan generator — there are enough of those. Something that takes the context of a specific venture and systematically surfaces the risks, constraints and opportunities that founders reliably miss:

    • Which of your assumed data sources are actually accessible, and under whose terms
    • Which regulatory obligations your data model triggers, and which architecture choice removes them
    • Where your infrastructure costs bend as you scale, and what a generic schema is worth
    • Which steps run on a clock you do not control, such as a mandatory testing window before a store release
    • And, before all of it, whether your Minimum Viable Segment actually overlaps in all five circles — including budget

    That is the same instinct behind the AI Solutions Hub: the value was never in knowing something rare, it was in making dispersed knowledge decidable.

    The learning nugget

    I set out to answer how do I build this? and spent three weeks getting excellent answers.

    The question I should have asked first was for whom, at what price, reached how? — because that answer would have changed the technology decisions, not the other way around.

    The frameworks are free. The mistakes are not.

  • Human or AI? What building an AI solutions catalogue taught me about pro’s and con’s of AI technology

    The trade-off between hand-checked data quality and AI-driven automation and why the right line between the two moves with scale.

    The setup

    For the past few months I’ve been building the AI Solutions Hub, a catalogue that documents which artificial intelligence insurers actually deploy in the Swiss market. The platform’s promise isn’t completeness at any cost; it’s reliability. Every entry rests on a source, and every source is graded for how much it can be trusted.

    The architecture behind it is quickly told: sources (insurer newsrooms, trade press, targeted web searches, manual tips) flow into an automation layer (scheduled crawler jobs and an interactive agent), pass through several AI quality gates, land in a Postgres database, and only then go public. Sounds linear. But the interesting part, and the real lesson isn’t in the architecture. It’s in a single seam: where does the machine stop and the human begin?

    The one sentence that governs everything

    A catalogue is worth only as much as the reliability of its weakest entry. Two naive positions follow from that sentence, and both are wrong:

    1. “A human has to check every entry.” – Highest quality, but doesn’t scale.
    2. “Just let the AI do it.” – Scales, but produces neatly formatted garbage.

    The whole craft lives in between. And here’s what I had underestimated: the right dividing line isn’t fixed. It shifts with volume.

    Why handwork doesn’t scale

    With five entries I read every source carefully, check every link, weigh every phrasing. That’s craft, and it’s good. With fifty it becomes a chore. With five hundred I lose the overview, not through carelessness, but because human attention is a finite resource. The crawler surfaces dozens of signals a week; nobody reads forty sources at 11 p.m. with the same care as at 9 in the morning.

    The subtler failure isn’t speed, it’s coverage: a duplicate resubmitted under a different name will almost inevitably slip past me in a list of two hundred entries. The human is the bottleneck and, worse, an unreliable bottleneck whose error rate climbs with fatigue.

    Why pure automation isn’t enough either

    The counter-test is sobering. Language models are confident and, at times, completely wrong. A concrete example from the project: I had executive-summary PDFs a chatbot had produced cleanly formatted, complete with citations. On inspection, roughly half the cited URLs were simply invented. Plausible, formatted, non-existent. Vendor marketing reads the same way as a real deployment: “AI-powered claims handling” except the text names no insurer that actually uses it. A model left to its own devices publishes exactly that: claims that look like evidence.

    The bridge: frameworks and thresholds

    Here’s the actual methodological insight. To automate a judgement, you first have to make it explicit.

    The Admiralty Code, a two-axis rating system from the intelligence world, in use for the better part of a century and today codified in NATO doctrine does exactly that. It breaks the diffuse question “how much do I trust this?” into two separate, nameable axes: the reliability of the source (A–F) and the credibility of the specific claim (1–6). An insurer press release picked up by independent trade press is a B1. A slick but unattributed landing page is an E4. Once the judgement is structured this way, a machine can propose it — it no longer has to sense it.

    The second lever is thresholds. A gut feeling (“this is probably relevant”) can’t be automated; a number can. On the platform, the relevance filter discards anything below a score of 0.75, and that value isn’t guessed, it’s derived from the data: every entry I ever approved scored ≥ 0.8; the junk I clicked away averaged 0.70. The threshold turns my past decisions into something operational.

    And third, the feedback loop: every rejection reason I note when discarding an entry flows back into the filter prompts as a negative example. The system gets a little stricter with each human decision. That’s how you raise the automation ceiling without lowering the quality floor.

    When the human is non-negotiable

    The rule of thumb that crystallised: automate the routine, escalate the exceptional. What stays with the human:

    • Defining the criteria themselves. That an entry only counts when a named insurer actively deploys the solution is a human stipulation, no model derives that on its own.
    • The top confidence tier. No algorithm awards itself a “verified.” A pipeline may propose a grade; the highest tier is a human-only decision.
    • The irreversible step. Publishing makes an entry public. I don’t hand that off without a safety net even at high AI confidence it only runs behind a multi-stage control gate.
    • Genuine edge cases with conflicting sources and the cases where the whole framing is wrong.

    The gate doesn’t decide the hard cases. It sorts: the clear ones pass through, the doubtful ones land on my desk.

    The counterintuitive part: when the model has the better overview

    And now the twist I didn’t see coming. “Human = quality, AI = speed” is too simple. For certain tasks, past a certain volume, the human is no longer the better guarantor of quality.

    The best example from the project: a duplicate that would have slipped through. Two entries described the same insurer deployment, one called “Claims Voicebot,” the other “AI voicebot for claims reports.” A fuzzy text match rated the name similarity at 0.33, far too low to trigger. And a human skimming a list of two hundred entries wouldn’t have connected the two either, the names are too different. What caught it was a semantic AI judgement that checked the new entry against every existing entry for the same insurer and concluded: this is the same solution.

    The point: at volume, consistency and total recall beat human attention. The model holds all five hundred entries in view at once, every time, without fatigue, without an off day. The human’s strength is judgement on the ambiguous single case; the model’s strength is the overview across the mass.

    The division of labour

    Better done by a humanBetter done by an LLM
    Defining the criteria (“what qualifies at all?”)Reading forty sources with steady care — at 11 p.m. as at 9 a.m.
    The irreversible sign-off (publishing publicly)Extracting structured fields and filling them in two languages
    Weighing conflicting edge casesApplying the same threshold identically — no drift, no off day
    Spotting when the whole framing is wrongCatching near-duplicates across languages (Claims ≈ claims reports)
    Awarding the top “verified” tierCross-reading every claim against the live source — on every entry

    The learning nugget

    The reflex to frame this as “human or machine” leads you astray. The real work is designing the seam between them. Three moves have proven their worth:

    1. Make the quality judgement explicit – with a framework like the Admiralty Code that turns “I trust this” into two nameable axes.
    2. Translate it into a threshold a machine can pass or fail.
    3. Reserve the human for the rare – definitions, edge cases, the irreversible.

    And the punchline that ties it together: the right dividing line shifts with volume. What needs a human at ten entries belongs automated at five hundred – and the human moves up a level: from checking individual rows to designing the system that checks them. Data quality doesn’t scale by checking more. It scales by engineering the checking itself well.

    Click here for an architectural overview

  • From AI Use Cases to AI Capabilities: A Maturity Model for Understanding the Evolution of AI

    Source: https://ai.marketeq.net/en

    Abstract

    Many organizations continue to manage artificial intelligence through use cases, applications, and vendor solutions. While this approach supports short-term implementation decisions, it becomes increasingly difficult to maintain as the AI landscape evolves. New solutions emerge weekly, capabilities converge, and previously distinct technologies become integrated into larger AI systems.

    This article proposes an alternative perspective: shifting from an AI Use Case Inventory towards an AI Capability Model. Building on current developments in Generative AI, Reasoning AI, Agentic AI, and Physical AI, this model focuses on understanding what AI can fundamentally perceive, understand, reason about, and execute.

    Based on this capability-centric view, a maturity framework and an AI Development Index (ADI) are introduced to systematically assess the technological maturity and business adoption of AI capabilities across industries, with particular relevance for insurance organizations.

    The Problem with Traditional AI Classification

    Historically, AI solutions have been categorized according to technologies.

    Typical classifications include:

    • Chatbots
    • Voicebots
    • OCR
    • Computer Vision
    • Machine Learning
    • Generative AI

    This approach was useful when technologies were largely isolated.

    Today, however, a modern AI solution rarely consists of a single technology.

    Consider a customer service voicebot.

    A modern voicebot typically combines:

    • Speech recognition
    • Natural language understanding
    • Retrieval systems
    • Large Language Models
    • Reasoning engines
    • Workflow automation
    • Speech synthesis

    The question therefore becomes:

    Is this solution a voicebot, an agent, a chatbot, a reasoning system, or a workflow engine?

    The answer is all of the above.

    Technology-based classification begins to lose explanatory power as AI systems become increasingly multimodal and interconnected.

    A Different Perspective: AI as an Evolving Set of Cognitive Capabilities

    A more durable approach is to classify AI according to the capabilities it possesses.

    This perspective aligns closely with observations made by Jensen Huang (Youtube Link), who frequently describes AI as a system that learns structures rather than merely processing language. That shows as well, what AI can not do.

    From this perspective, AI evolves similarly to human cognition.

    The central question becomes:

    What aspects of reality can an AI system understand?

    This shift creates a more stable framework because capabilities evolve more slowly than products and technologies.

    The First Dimension: Understanding

    The first major capability layer concerns understanding.

    Every meaningful AI system must first develop an understanding of a particular domain before it can reason or act within it.

    Understanding Human Language

    This is the capability most organizations associate with AI today.

    The AI understands:

    • Text
    • Documents
    • Policies
    • Contracts
    • Emails
    • Conversations

    Insurance examples include:

    • Claims assistants
    • Underwriting copilots
    • Legal review systems
    • Compliance assistants

    This capability has already reached high maturity.

    Most modern foundation models demonstrate strong performance in this domain.

    Understanding Human Voice

    The next capability extends language understanding into spoken interaction.

    The AI understands:

    • Spoken language
    • Conversational context
    • Accents
    • Dialogue structure

    Insurance examples include:

    • First Notice of Loss (FNOL) voice assistants
    • Broker support systems
    • Customer service automation

    The focus is no longer on speech recognition alone.

    The capability involves understanding intent and context throughout an entire interaction.

    Understanding Images

    Computer Vision systems enable AI to interpret visual information.

    Examples include:

    • Vehicle damage recognition
    • Property damage assessment
    • Medical image analysis
    • Fraud detection

    Today, many image-based insurance applications focus on identifying visible objects and damage patterns.

    For example:

    • Broken windshield
    • Dented bumper
    • Water damage
    • Roof deterioration

    This represents an important but still relatively narrow level of understanding.

    Understanding Physics

    A significantly more advanced capability emerges when AI moves beyond identifying objects and begins understanding physical causality.

    This is one of the most important future developments for insurance.

    The AI understands:

    • Forces
    • Material behavior
    • Impact dynamics
    • Energy transfer
    • Structural deformation

    Consider a vehicle accident.

    Current image recognition systems may identify:

    • A damaged door
    • A broken headlight
    • Scratches on a vehicle

    A physics-aware AI would additionally reason:

    • From which direction did the collision occur?
    • Is the observed deformation consistent with the reported accident description?
    • What speed range likely caused the observed damage?
    • Which secondary damages should be expected?

    The AI is no longer simply recognizing damage.

    It is reconstructing reality.

    This represents a fundamentally higher level of intelligence.

    For insurance claims management, this capability could become transformative.

    Future systems may automatically assess:

    • Plausibility of claims
    • Fraud indicators
    • Estimated impact forces
    • Repair implications

    The transition from “understanding images” to “understanding physics” represents a major maturity leap.

    Understanding Human Behaviour

    Another capability layer focuses on behavioral patterns.

    The AI understands:

    • Customer preferences
    • Decision patterns
    • Behavioral anomalies
    • Fraud indicators

    Applications include:

    • Churn prediction
    • Recommendation systems
    • Fraud detection
    • Customer journey optimization

    Understanding Business Processes

    AI increasingly learns how organizations operate.

    The AI understands:

    • Process flows
    • Escalation paths
    • Dependencies
    • Operational bottlenecks

    This capability enables process automation and process mining.

    Understanding Financial Systems

    This capability focuses on economic and financial relationships.

    Examples include:

    • Market dynamics
    • Asset correlations
    • Pricing mechanisms
    • Risk structures

    Applications include:

    • Asset management
    • Pricing optimization
    • Reserving
    • Capital modelling

    Understanding Biology

    One of the most advanced emerging capabilities.

    The AI understands:

    • Proteins
    • Molecules
    • Genes
    • Cellular interactions

    Although primarily relevant for healthcare today, long-term implications for health insurance and life insurance could be substantial.

    As AI capabilities continue to mature, access to data alone will no longer be a sufficient competitive advantage. Organizations will increasingly need to make tacit knowledge accessible – the expertise, judgment, contextual understanding, and practical experience that have historically remained undocumented. Future AI systems will derive substantial value not only from understanding documents, images, voice, or physical reality, but also from learning and operationalizing the collective knowledge embedded within the organization itself. The ability to transform human expertise into organizational intelligence may become one of the most important differentiators of the next generation of AI-enabled enterprises.

    In insurance, some of the most valuable knowledge often resides in experienced claims handlers, underwriters, sales people, actuaries, fraud specialists, and compliance experts. Their ability to recognize patterns, assess exceptions, interpret incomplete information, and apply contextual judgment is frequently not documented in systems or processes. Capturing and augmenting this expertise may represent the next major frontier beyond Generative AI and Agentic AI, enabling organizations to build AI systems that not only process information but also preserve and scale institutional knowledge.

    Understand Data → Understand Physics → Understand Human Expertise (tacit knowledge) → Understand Reality

    Beyond Understanding: The Capability Hierarchy

    Understanding alone does not create business value.

    Once AI understands a domain, additional capability layers emerge.

    Generate

    The AI creates new outputs.

    Examples:

    • Text
    • Speech
    • Images
    • Video
    • Code

    Reason

    The AI performs structured analysis.

    Examples:

    • Root cause analysis
    • Risk assessments
    • Recommendation generation
    • Multi-step problem solving

    Decide

    The AI proposes decisions.

    Examples:

    • Risk recommendations
    • Prioritization
    • Next-best-action suggestions

    Act

    The AI executes tasks.

    Examples:

    • Updating systems
    • Triggering workflows
    • Creating claims records
    • Scheduling actions

    Collaborate

    Multiple AI agents cooperate.

    Examples:

    • Claims handling ecosystems
    • Multi-agent underwriting
    • Autonomous process orchestration

    Why a Maturity Model Becomes Necessary

    As organizations adopt more AI capabilities, a new challenge emerges.

    Not all capabilities are equally mature.

    For example:

    Text understanding is highly mature.

    Physics understanding remains an emerging capability.

    Yet both may appear under the broad label of “AI”.

    Without a maturity model, executives cannot distinguish between:

    • Proven capabilities
    • Emerging capabilities
    • Experimental capabilities

    This leads to unrealistic expectations and poor investment decisions.

    Capability Maturity Score (CMS)

    The first component of the model measures technological maturity.

    ScoreMaturity
    1Research
    2Experimental
    3Emerging Market
    4Commercially Available
    5Enterprise Ready
    6Commodity Capability

    Example:

    CapabilityCMS
    Text Understanding6
    Voice Understanding5
    Image Understanding5
    Physics Understanding2
    Agentic Execution3
    Multi-Agent Collaboration2

    Business Adoption Score (BAS)

    Technological maturity alone is insufficient.

    Organizations must also understand adoption.

    ScoreAdoption
    1No Adoption
    2Proof of Concept
    3Pilot
    4Productive Use
    5Enterprise Scale
    6Industry Standard

    Example:

    CapabilityBAS
    Text Understanding6
    Voice Understanding4
    Image Understanding4
    Physics Understanding1
    Agentic Execution2

    The AI Development Index (ADI)

    Combining both dimensions creates a more meaningful measure.

    The AI Development Index is calculated as:

    ADI = Capability Maturity Score × Business Adoption Score

    This creates a dynamic measure that reflects both:

    • Technical feasibility
    • Real-world business utilization

    Example:

    CapabilityCMSBASADI
    Text Understanding6636
    Voice Understanding5420
    Image Understanding5420
    Physics Understanding212
    Agentic Execution326

    Strategic Value of the AI Development Index

    The AI Development Index enables leaders to answer questions that traditional AI inventories cannot.

    For example:

    • Which AI capabilities are already mature?
    • Which capabilities should be piloted today?
    • Which capabilities should be monitored?
    • Which capabilities remain too immature for production deployment?
    • Which future developments could fundamentally reshape insurance?

    Most importantly, it shifts the conversation away from vendors and products.

    Instead, it focuses attention on the underlying evolution of intelligence itself.

    Conclusion

    The future of AI governance, portfolio management, and strategic planning will likely move beyond cataloging use cases and technologies.

    A capability-centric perspective provides a more stable framework for understanding how artificial intelligence evolves.

    The proposed model follows a simple logic:

    Understand → Generate → Reason → Decide → Act → Collaborate

    In regards to “understanding”, the generated output will increase in perceived quality, if more understanding as capability growths (e.g., physics, tacit knowledge, reality).

    Within this framework, the maturity of individual capabilities can be measured through the Capability Maturity Score and their business relevance through the Business Adoption Score.

    Together, these dimensions form the AI Development Index, creating a structured and measurable view of the evolution of artificial intelligence.

    For industries such as insurance, this approach provides not only a better understanding of today’s capabilities, but also a roadmap for identifying the next generation of AI systems that will emerge over the coming decade.

  • Beyond AI Use Cases: Why I created an AI Solution Hub

    Over the past two years, I have had countless discussions with executives, business leaders, and AI practitioners about the future impact of artificial intelligence as part of my role for AI Strategy, Portfolio & Steering.

    One question appears in almost every conversation:

    Which jobs will AI replace?

    While understandable, I believe this is increasingly the wrong question. A more useful question is:

    Which activities within a role will no longer require human effort
    because AI can perform them more effectively, consistently, and at scale?

    This shift in perspective fundamentally changes how organizations should think about AI transformation.

    AI is changing tasks before it changes jobs

    Recent research from leading institutions such as MIT, Harvard Business School, and McKinsey points in a similar direction.

    AI is not primarily replacing professions. It is progressively taking over specific tasks within professions.

    Jensen Huang, CEO of NVIDIA, recently described this distinction as the difference between a person’s tasks and their purpose.

    In many cases, AI can automate significant portions of information-intensive work while leaving the actual business responsibility with the human expert.

    Consider an insurance underwriter. The purpose of the underwriter is not reading documents. The purpose is making sound risk decisions.

    Yet a large portion of the role today still involves gathering information, reviewing reports, validating data, and preparing analyses.

    These are precisely the activities that AI is becoming increasingly capable of handling.

    The same applies to claims management, compliance, finance, legal, HR, and many other business functions.

    The future is not AI replacing humans

    In my view, the future is better described as a redistribution of work.

    Historically, knowledge workers spent significant time on:

    • Searching
    • Reading
    • Summarizing
    • Documenting
    • Reporting

    Today, AI is rapidly taking over these activities. As a result, human work shifts towards:

    • Judgment
    • Prioritization
    • Governance
    • Stakeholder management
    • Decision accountability

    This is particularly relevant in highly regulated industries such as insurance, where accountability and human oversight remain essential.

    The question therefore becomes:

    How do we systematically understand which capabilities AI can already perform, which capabilities are emerging, and where humans will continue to play a critical role?

    Understanding the evolution of AI capabilities

    When viewed from a strategic perspective, AI capabilities are evolving through several distinct stages.

    Predictive AI

    The first wave focused on prediction.

    Examples include:

    • Fraud detection
    • Customer churn prediction
    • Risk scoring
    • Pricing optimization

    Generative AI

    The second wave focused on content creation.

    Examples include:

    • Text generation
    • Document summarization
    • Translation
    • Image generation

    Reasoning AI

    We are now entering a phase where AI increasingly performs structured analysis and problem solving.

    Examples include:

    • Complex case assessment
    • Risk analysis
    • Compliance reviews
    • Decision support

    Agentic AI

    The next wave goes beyond analysis.

    AI agents are beginning to execute complete workflows.

    This includes:

    • Gathering information
    • Using software tools
    • Performing actions
    • Coordinating multiple systems
    • Escalating exceptions

    This is where AI starts moving from being an assistant towards becoming a digital workforce.

    The capability question becomes a leadership question

    The most important challenge is no longer technological.

    It is managerial.

    Leaders need to understand:

    • Which activities create value?
    • Which activities can be delegated to AI?
    • Which decisions require human accountability?
    • Which new skills become critical?

    Organizations that answer these questions effectively will likely outperform those that focus solely on technology adoption.

    Looking ahead

    I believe we are only at the beginning of a much larger transformation.

    The conversation will gradually move away from chatbots and isolated use cases.

    Instead, organizations will increasingly focus on orchestrating collaboration between humans and AI systems.

    Understanding this shift requires more than experimenting with new tools.

    It requires a structured understanding of AI capabilities, business value, governance, and organizational readiness.

    This is exactly why I have created the AI Solution Hub.

    It is already being used to provide a structured view of AI capabilities, business use cases, opportunities, limitations, and governance considerations across different domains.

    Why I created an AI Solution Hub

    The purpose is simple.

    Organizations are currently overwhelmed by thousands of AI products, copilots, agents, platforms, and use cases.

    At the same time, expectations often exceed reality.

    Some believe AI can already solve almost everything. Others underestimate how quickly capabilities are evolving.

    The AI Solution Hub aims to create transparency.

    It provides a structured overview of:

    • Existing AI capabilities
    • Emerging AI capabilities
    • Relevant business use cases
    • Opportunities
    • Limitations
    • Governance requirements
    • Risk considerations

    Most importantly, it helps separate hype from practical business value.

    Its purpose is not to track technology for its own sake.

    Its purpose is to help organizations better understand what AI can realistically do today, what is emerging, and where human expertise will remain indispensable. A key principle behind the platform is trust. As I discussed in my previous blog post, trustworthy AI decisions require trustworthy data. Therefore, the information and assessments within the hub are evaluated using a structured methodology inspired by NASA’s Technology Readiness Level (TRL) framework, helping organizations understand not only what is technically possible but also how mature and reliable a capability is in practice. In addition, the platform provides a market perspective by continuously monitoring AI solutions, vendors, and emerging trends, enabling leaders to make informed decisions based on both capability maturity and market developments.

    If you are exploring how AI can create value in your organization and want a more structured way to navigate the rapidly evolving AI landscape, I invite you to take a closer look at the AI Solution Hub and see how it can support your AI journey.

    www.ai.marketeq.net

  • Scaling AI w/ Portfolio Leadership

    Why AI Portfolio Leadership is Crucial for the Future of Our Business

    As artificial intelligence (AI) continues to transform the insurance industry, companies face a growing challenge: how to strategically manage and scale AI initiatives across complex organizations. This is where the role of an AI Portfolio Leadbecomes not only relevant — but essential.

    Building an AI Portfolio with Purpose

    AI is no longer about isolated pilots or one-off innovations. To drive real business value, organizations must take a holistic view. As an AI Portfolio Lead, my mission is to build and steer an AI portfolio that is fully aligned with our company’s business strategy and digital transformation goals.

    By establishing an AI inventory (which we are currently implementing in Collibra), we ensure transparency and structure:
    👉 Which AI use cases exist?
    👉 Where are synergies?
    👉 How can we scale proven solutions across markets?

    This systematic approach helps us avoid duplicated efforts, ensures regulatory compliance across different Market Units (such as Switzerland and the EU), and maximizes the return on AI investments.

    Prioritization and Governance

    Not all AI use cases deliver equal value. One of the most important aspects of my work is the evaluation and prioritization of AI initiatives:

    • Which use cases offer the greatest business impact?
    • What are the technological and regulatory risks?
    • How mature and ready is the organization to adopt them?

    Through this governance, we ensure that we focus our resources on those AI projects that create real business outcomes — whether that’s operational efficiency, better customer experience, or even new revenue streams.

    Trust is the foundation of every successful organization.

    Fredmund Malik, 2000

    Navigating Compliance and Trust

    In the European insurance industry, compliance is non-negotiable — especially with the introduction of the EU AI Actand updates to data privacy regulations such as DSGVO and Swiss Data Protection Law.

    A key part of my responsibility is ensuring that all AI use cases meet these regulatory standards and can be trusted by customers, employees, and regulators alike. Without this trust, even the most advanced AI will not succeed.

    Building the Foundation: Trust, Adoption, and Scalability

    In the insurance industry, trust is everything. It is the foundation on which customers choose to take out an insurance policy — trusting that the company will be there when it matters most.

    As we bring AI into more processes and customer interactions, this core value must be upheld. AI Trust means that our AI systems must be:
    ✅ transparent (customers and regulators understand what AI does and why),
    ✅ fair (free from bias and discrimination),
    ✅ robust (perform reliably even in edge cases),
    ✅ explainable (decisions and outcomes are understandable to humans), and
    ✅ aligned with legal and ethical standards (such as the EU AI Act and local regulations).

    Without trust in AI, adoption will stall — internally and externally.

    Driving AI Adoption

    Building trustworthy AI is the starting point. The next step is ensuring that AI adoption happens meaningfully within the organization:
    ✅ By fostering AI literacy and understanding across business units,
    ✅ By embedding AI into core processes rather than treating it as a side project,
    ✅ By involving stakeholders early, including compliance, legal, and business leaders, to ensure buy-in and alignment.

    AI adoption is not just about deploying technology — it is about changing how we work, supported by AI.

    Scaling AI for Business Impact

    Finally, once trust and adoption are in place, we focus on scaling AI use cases:
    ✅ Identifying successful pilots that can be scaled across markets or product lines,
    ✅ Building AI platforms and shared capabilities to avoid reinventing the wheel for each project,
    ✅ Creating feedback loops to continuously improve AI models as they scale,
    ✅ Ensuring scalability respects regulatory differences across jurisdictions.

    In this way, AI becomes not just a collection of isolated experiments — but an integrated, trusted enabler of enterprise-wide transformation.

    Measuring Success and Scaling Value

    Finally, success must be measurable. We define KPIs for each AI use case — from accuracy and efficiency gains to business impact — and continuously monitor progress.

    More importantly, we identify scaling potential: AI that works well in one unit or country can often be adapted and expanded elsewhere, accelerating overall digital transformation.

    In Conclusion

    AI has immense potential to reshape how we operate and serve our customers. But without strong portfolio leadership, that potential risks becoming fragmented, siloed, and ungoverned.

    As AI Portfolio Lead, my job is to ensure that we drive AI forward — strategically, responsibly, and with measurable business value. In this way, we turn AI from an experimental technology into a trusted, scalable enabler of our company’s future success.