From legal PDFs to precise, personalized answers: GenAI myUNIQA at UNIQA Insurance Group AG

Why UNIQA brought GenAI into myUNIQA

In “GenAI myUNIQA,” Aleksandar Kamenica (Product Owner, Technology Exploration, UNIQA Insurance Group AG) walks through a grounded engineering story: customers struggle to understand their insurance contracts. This isn’t intuition—it’s backed by research across the Austrian market and among myUNIQA users. The common thread across concerns—from benefits and coverage to deductibles, documents, claims, and payments—is understanding.

The hard constraint: the legally binding truth lives only in documents. There is no clean, canonical structured database UNIQA can simply query for every question. The goal is therefore to transform heterogeneous, legally binding documents into clear, personalized answers—always correct for the individual product configuration and always faithful to the source.

Kamenica’s target state: turn document stacks into immediate, trustworthy, and visually clear answers inside myUNIQA.

The team and enabling groundwork

UNIQA’s Technology Exploration Team is cross-functional with two mandates:

• Test and apply technologies not yet used at UNIQA.
• Find technical solutions to demanding business problems.

Foundational work that enabled this GenAI journey:

• Migrating myUNIQA to public cloud infrastructure (AWS)—a “major leap” and, as Kamenica notes, an important puzzle piece for AI work.
• Selecting and establishing the frontend stack for customer-facing applications.
• Moving customer identity and access management from on-prem to the cloud.

These cloud moves lowered the barrier to exploring GenAI—an explicit learning Kamenica highlights later.

Problem definition: personalized answers from legally binding documents

UNIQA’s “customer first” isn’t just a metric; it informs product direction. The research made it clear that many customers don’t understand key contractual details. At the same time, the only legally authoritative information sits in documents. There’s no ready-made structured dataset to answer the questions.

The desired experience: a customer opens a specific contract in myUNIQA (say, household insurance) and sees predefined questions with personalized answers—based on the product and its add-ons in that customer’s unique configuration. Kamenica uses the “Lego” metaphor: each product consists of many bricks, each with its own legal content. Answers must reflect the combined configuration.

Vision and a pragmatic Phase 1

The long-term vision is a direct AI assistant that can answer any insurance-related question in real time, grounded in UNIQA-specific knowledge. But Phase 1 deliberately focuses on “indirect AI involvement”:

• A common set of predefined questions per product area.
• Answers are personalized but generated offline.
• The AI pre-computes answers for each document combination.
• Answers are stored in a database and displayed in the app.

Why not a content management system? Because the answers must be derived from legal sources and cover all combinations. Manual maintenance would be unscalable and risky. In Phase 1, AI creates the content, but customers do not yet interact with the model directly.

First approach: RAG with chunking—then hard edges

The team started with Retrieval-Augmented Generation (RAG): splitting documents into chunks with overlaps. In practice, several factors made this brittle:

• Relevant passages often span multiple pages.
• Document structures vary widely (articles, bold/italic headings, inconsistent formatting), making semantic chunking hard.
• Fixed-size chunking yielded partial answers—acceptable for a demo, insufficient for production-grade completeness.

The takeaway wasn’t that RAG is wrong, but that the required effort for robust chunking outweighed the benefits in this specific document landscape.

The pivot: large context windows over complex chunking

As the project progressed, models with large context windows (Kamenica mentions 128,000 tokens) became available. The team could now place all relevant content for a given question into a single prompt—eliminating the need for chunking. This enabled complete answers grounded in the full set of relevant documents.

Technically, this addressed the recall and completeness problem. But the semantic requirements remained: ensure answers are truthful, sourced exclusively from the documents, and free of contradictions.

The tough part: resolving contradictions (the “terrorism” clause)

A real example Kamenica highlights is the “terrorism” clause. A higher-level document states an exclusion, while product-level documents do not. For a customer’s specific configuration, which statement wins?

The solution was to model document precedence:

• “Main documents”: product-near, specific documents tied to the configuration.
• “Additional documents”: higher-level, more general documents.

Prompt logic: answer from main documents first; consult additional documents only if needed and to resolve conflicts. With that, the terrorism case stopped producing spurious exclusions and became consistent with the customer’s actual product configuration.

As Kamenica stresses, this hinges on domain understanding—the team had to know how products and documents are layered to encode the right decision rules into the prompt.

Prompt evolution: from Markdown to structured JSON

The implementation journey began in a Jupyter notebook: initialize the LLM (e.g., GPT-4 with a large context window), load documents, iterate prompts, validate outputs—and later move to serverless functions for consistent execution.

Key stages in the prompt lifecycle:

1. Grounded answering with a truth constraint:

• Only answer using the supplied additional information.
• If an answer is not derivable, return “false”—do not invent content.
• Objective: prevent the model from blending in general training knowledge; keep it firmly grounded in the provided sources.

1. Markdown formatting for early validation:

• Render answers in Markdown for easy human review.
• Include sources; strip legal enumeration artifacts (e.g., “Article 1, 2, 3”).
• Avoid introductory fluff.

1. Document precedence in the prompt:

• Encode main vs. additional documents and the conflict-resolution rule.
• This unblocked cases like the terrorism clause.

1. Language choice:

• Experiments in English and German; settled on German to match the documents and, in practice, get better results.

1. Transition to JSON output:

• Goal: integrate natively into the myUNIQA UI; avoid rendering Markdown.
• Approach: provide an exemplar JSON schema (title, sections, subsections, bullets, positive/negative flags, sources) and instruct the model to fill it.
• Constraint: “Do not invent new attributes.” The model’s creativity—initially useful—had to be constrained to ensure stable, contractible outputs.

The result is a robust, structured JSON response that the frontend can map to components (accordions, bullet lists, icons). The positive/negative flags drive clear visual cues (e.g., checkmarks for covered risks).

Data pipeline and generation workflow

To drive generation, the team prepared a CSV that enumerated combinations: which main documents, which additional documents, and which question. The process:

• Load the listed documents and inject them as text into the prompt.
• Iterate row by row; generate an answer per (documents, question) tuple.
• Validate and write the structured JSON answer to a database, keyed by the document combination.

A pragmatic operational note: Kamenica observed that a single answer can take two to three minutes to generate. That’s too slow for live interaction, but acceptable for offline precomputation—the key rationale for Phase 1’s “indirect AI” approach.

Frontend rendering: turning JSON into clarity

In the demo, a household insurance contract displays predefined questions like “Which risks are insured?” The answer appears as multiple collapsible sections—e.g., “Fire” and “Explosion”—each enriched with definitions and clarifications.

Notable UI behaviors:

• Positive/negative flags map to icons (checkmarks for insured items, etc.).
• Accordions manage long, detailed answers without overwhelming the screen.
• Sources are listed; content can be verified against the original documents.
• Bundled products (e.g., household and liability) are navigable at their respective levels with the right personalized answers.

The effect is a visually appealing, trustworthy summary—strictly derived from legal documents.

Architecture path: from notebook to serverless—and why cloud mattered

Development began in a Jupyter notebook with Python-based iteration. As patterns stabilized, the logic moved into serverless functions for consistent, repeatable execution. Generated answers, together with their source references and document combination keys, are stored for the app to retrieve and render.

Kamenica underlines that being on AWS made this journey easier: new services could be tried quickly without upfront approvals, and architectural decisions could be evaluated in parallel with experimentation.

Quality pillars: truthfulness, completeness, sources, consistency

The system’s quality criteria are explicit:

• Truthfulness: answers must come only from the provided documents.
• Completeness: with large context windows, include all relevant passages; avoid partial answers.
• Sources: include document references in the JSON so every statement is traceable.
• Consistency: resolve conflicts between document layers deterministically (main before additional, with defined exceptions).

Achieving these outcomes is what the prompt evolution—and the shift to a strict JSON schema—was all about.

Lessons learned: three clear takeaways

Kamenica closes with concise lessons:

• Because myUNIQA was already in AWS, the team could start quickly and explore services without friction.

• The team pivoted from RAG to leveraging large context windows as soon as those models arrived and proved promising.

• Knowing the domain—how products and documents are layered—was essential for encoding the main vs. additional document logic that resolves contradictions.

What engineers can apply from this talk

• Domain modeling meets prompting: the model will not invent business rules; you must encode document precedence and truth constraints explicitly.
• Start with human-verifiable output: Markdown accelerates review, but a strict JSON schema is key for production integration.
• Choose offline generation when latency and quality demand it: “indirect AI” is a pragmatic first step in regulated contexts.
• Build on cloud foundations: having the app and IAM already in the cloud enabled fast experimentation and a clean path to serverless productionization.
• Track model capabilities: large context windows can flip the build-vs.-chunk calculus for unstructured legal documents.

Conclusion: a disciplined path to trustworthy answers

“GenAI myUNIQA” is a disciplined, customer-first application of GenAI. Aleksandar Kamenica and the Technology Exploration Team progressed from RAG experiments to a robust JSON-answering pipeline grounded solely in legal documents—complete with document precedence rules, explicit sources, and UI-ready structure.

The outcome is precise, personalized answers in myUNIQA that combine legal fidelity with user-friendly presentation. It lays solid groundwork for future phases that move toward direct AI interaction—while demonstrating how fast-moving model capabilities can be harnessed when you truly understand your data and shape your prompts accordingly.

• 

  

  Christoph Gruber, Head of IT Security bei UNIQA

  Christoph Gruber von UNIQA gibt im Interview Einblicke in die Organisation der Teams in der IT, welche Grundgedanken es bei der Wahl der jeweiligen Technologien gibt, sowie wie das Recruiting und Onboarding gestaltet ist.

  Watch now

• 

  

  Eva-Maria Tscherne, Business Analyst bei UNIQA

  Eva-Maria Tscherne von UNIQA spricht im Interview über ihren Background wie sie zur Business Analyse gekommen ist und was ihre aktuelle Rolle beinhaltet und gibt Tipps zur Weiterentwicklung.

  Watch now
• 

  

  Martin Fuger, Test Analyst bei UNIQA

  Martin Fuger von UNIQA erzählt im Interview darüber, wie er zur Test Analyse gekommen ist, wie dort der Tagesablauf in der Arbeit aussieht und welche Dinge seiner Ansicht nach für Neueinsteiger wichtig sind.

  Watch now
• 

  

  Barbara Sikora, Product Owner bei UNIQA

  Barbara Sikora von UNIQA spricht im Interview über ihren Werdegang bis hin zur aktuellen Arbeit als Product Owner und gibt Tipps für Anfänger.

  Watch now