AI product engineering for money-critical systems.https://zeroevoke.com/enhttps://zeroevoke.com/blog/ai-automation-without-losing-control/https://zeroevoke.com/blog/ai-automation-without-losing-control/AI automation is only a win if control survives it: separate recommendation from action, keep a manual path, and make every outcome reconstructable.Wed, 09 Sep 2026 00:00:00 GMTThe promise of AI automation is simple: remove manual work. The risk is just as simple: remove the controls at the same time. In financial services, a faster workflow is not an improvement if nobody can explain what happened, correct a bad outcome or stop the system when conditions change. ## Automate the Work, Not the Accountability Many operational processes contain tasks that are expensive because people repeatedly read, compare, copy, classify and summarize information. AI can do much of that work. But the organization still needs a clear owner for the outcome. Automation should reduce the effort required to reach a decision or complete a process; it should not make responsibility ambiguous. ## Separate Recommendation From Action One of the safest design patterns is to separate what the AI recommends from what the system is allowed to do. An AI component can extract data, flag anomalies, draft a response or recommend a next step. A policy engine, workflow rule or authorized person can then approve the action. As confidence grows, some low-risk actions can become automatic while higher-impact cases keep a human checkpoint. ## Build for Uncertainty AI systems should be allowed to say they are unsure. Confidence thresholds, validation rules and escalation paths are part of the product, not afterthoughts. If a document is unreadable, a policy is ambiguous or two sources disagree, the correct output may be “send this case to review” rather than forcing an answer. ## Everything Important Should Be Reconstructable For each automated outcome, retain the evidence that mattered: source documents, extracted fields, rule results, model outputs, reviewer actions and timestamps. Version the policies and models that were active at the time. If an internal audit or customer complaint appears months later, the team should be able to reconstruct exactly what the system saw and why it behaved the way it did. ## Design a Manual Path Before You Need It Every automated workflow needs a practical fallback. What happens if the model provider is unavailable? What if confidence suddenly drops? What if a new document format appears? What if operations needs to override the workflow? The manual path should be tested before production, not invented during an incident. ## Good Automation Feels Controlled The best AI automation does not make an organization feel less certain. It makes repetitive work disappear while making the important decisions easier to inspect. That is the standard to aim for: more automation, fewer manual steps and stronger operational control at the same time.EngineeringGovernanceRiskShahaf Lavihttps://zeroevoke.com/blog/where-llms-belong-in-financial-services/https://zeroevoke.com/blog/where-llms-belong-in-financial-services/LLMs earn their place in finance on the messy language around the core systems — not on the money movement or the regulated decisions themselves.Wed, 02 Sep 2026 00:00:00 GMTLarge language models are useful in financial services, but not for the reason most demos make them look useful. Their strongest role is usually not to replace the core systems that move money or make regulated decisions. It is to handle the messy language and document-heavy work around those systems. ## Use LLMs Where the Input Is Unstructured Financial operations contain enormous amounts of information that was written for people rather than software: policies, emails, PDFs, customer explanations, contracts, bank statements, case notes and internal procedures. LLMs are good at reading, classifying, extracting and summarizing that material. They can turn a pile of documents into structured fields, identify missing information, compare a case against policy and prepare a reviewer with the relevant facts. ## Keep Deterministic Systems Where Precision Matters Some parts of a financial system should remain deliberately boring. Payment amounts, eligibility rules, exposure limits, calculations, ledger entries and hard policy constraints should not depend on a model improvising the answer. If the outcome must be exact every time, deterministic code, validated formulas and explicit rules are usually the right tools. ## The Best Pattern Is LLM Plus Guardrails A production LLM should normally operate inside a controlled workflow. Give it a narrow task. Limit what information it can access. Require structured output. Validate the result. Preserve source references. Route low-confidence or unusual cases to a person. Log the prompt, model version and final action. The model can do the interpretation, but the surrounding system should decide what happens next. ## Do Not Confuse a Good Demo With a Reliable System An impressive chat interface can hide fragile behaviour. The hard work starts after the demo: evaluation, permissions, fallbacks, monitoring, prompt and model versioning, cost control, data retention and failure handling. A financial-services implementation needs to be judged on repeatability and operational risk, not on how convincing one example looks. ## Where We See the Most Value The practical opportunities are often document intake, operations support, policy interpretation, case summarization, analyst assistance, exception handling, customer-service augmentation and internal knowledge workflows. In each case the LLM reduces the amount of reading and repetitive manual interpretation required from people. ## LLMs Should Remove Friction, Not Control The useful question is not “Where can we put an LLM?” It is “Which parts of this workflow are dominated by language, documents or repetitive interpretation?” Put the model there. Keep the money movement, hard controls and final accountability in systems designed for precision.EngineeringOpinionShahaf Lavihttps://zeroevoke.com/blog/how-ai-changes-modern-underwriting-engines/https://zeroevoke.com/blog/how-ai-changes-modern-underwriting-engines/AI’s biggest change to underwriting lands before the decision: it turns unstructured documents and transactions into evidence rules and models can use.Wed, 26 Aug 2026 00:00:00 GMTThe biggest change AI brings to underwriting is not that it replaces the decision engine. It changes what the decision engine can see, how quickly it can interpret information, and how much manual work can happen before a final decision is made. ## The Old Model Was Mostly Structured Traditional underwriting engines were built around structured inputs: bureau attributes, declared income, bank-account fields, policy rules, scorecards and thresholds. That architecture is still useful because it is predictable, fast and easy to audit. The weakness is that a large part of a real credit file does not arrive neatly structured. Documents, transaction descriptions, business activity, explanations, exceptions and supporting evidence often sit outside the core decision logic. ## AI Expands the Inputs Before It Changes the Decision Modern AI can turn that unstructured layer into usable signals. It can extract information from documents, classify cash-flow events, identify inconsistencies, summarize complex files and surface patterns for review. That does not mean an AI model should make every approval or decline. In many systems the highest-value use of AI is earlier in the pipeline: converting messy information into structured evidence that policy rules, statistical models and human reviewers can use. ## Rules, Models and AI Each Have a Different Job The strongest underwriting architecture is usually hybrid. Rules are good for hard policy constraints: eligibility, product limits, required documentation and prohibited conditions. Predictive models are good at estimating risk from repeatable historical patterns. AI is especially useful where the inputs are messy, variable or language-heavy. Human review remains important where context, exceptions or accountability matter. ## Explainability Still Wins A better model is not useful if the organization cannot explain why a decision happened. Every material input should be traceable. Rules should be versioned. Model outputs should be logged. AI-derived information should retain links to the source evidence that produced it. If a reviewer cannot reconstruct the path from raw information to final decision, the system is not ready for production. ## The Real Opportunity Is a Better Decisioning System The future underwriting engine is not one giant AI model. It is a controlled system in which AI improves information quality, models improve prediction, rules enforce policy and humans handle the cases that genuinely require judgment. The result should be faster decisions, less manual work and better consistency without giving up control.UnderwritingEngineeringShahaf Lavihttps://zeroevoke.com/blog/risk-committee-questions/https://zeroevoke.com/blog/risk-committee-questions/The eleven questions that decide whether a system ships, and the artefact that answers each one before it is asked.Wed, 12 Aug 2026 00:00:00 GMTTeams usually prepare for the wrong meeting. They arrive with accuracy metrics and leave with eleven questions about everything else. Here is the list, and the artefact that answers each one. A risk committee is not evaluating your model. It is evaluating whether the organisation can defend a decision the model made, eighteen months from now, to someone who was not in the room. Once you accept that, the questions stop feeling arbitrary. ## The eleven questions 1. **What decision does this make, and what happens if it is wrong?** Answered by a one-page decision description, not an architecture diagram. 2. **Where does every input come from?** Answered by data lineage — source system, owner, refresh interval, and what happens when it is stale. 3. **Who can override it, and is the override recorded?** Answered by the override path in the product, plus a sample of the audit log. 4. **How do you know it is still working?** Answered by the monitoring plan: which metrics, which thresholds, who is paged. 5. **What does it do with a customer it has never seen before?** Answered by the out-of-distribution policy and the fallback decision. 6. **Can it discriminate?** Answered by a fairness assessment across protected characteristics, with the methodology stated. 7. **Who approved the current version, and when?** Answered by a model register entry with a version, a date and a name. 8. **How would we turn it off?** Answered by a documented kill switch that someone has actually tested. 9. **What is the challenger, and how does it compare?** Answered by a side-by-side over the same period. 10. **Can you reproduce a decision from six months ago?** Answered by versioned inputs, code and model weights. 11. **Who owns it after go-live?** Answered by a named person in the operating model — not a team, a person. > If a question takes more than a sentence to answer, the answer is not ready. > Write the artefact instead of preparing the explanation. ## Build the pack while you build the system The teams that clear committee in one sitting are not better at presenting. They produced these artefacts as a by-product of building, because each one is genuinely useful during development — lineage prevents silent breakage, monitoring catches drift, the register stops two people shipping different versions. The teams that take three sittings write the pack afterwards, from memory, under time pressure. The gaps in the pack are the gaps in the system; the committee is simply the first party to read them out loud. ## What to bring One binder, eleven tabs, one page each. Accuracy metrics go in an appendix. Lead with the decision, the failure mode and the person who owns it — in that order.RiskUnderwritingGovernanceShahaf Lavihttps://zeroevoke.com/blog/eleven-weeks-to-a-live-decisioning-engine/https://zeroevoke.com/blog/eleven-weeks-to-a-live-decisioning-engine/A week-by-week account of one engagement, including the two weeks we lost and what we would do differently next time.Wed, 29 Jul 2026 00:00:00 GMTEleven weeks from kickoff to the first real application scored in production. Not a pilot, not a shadow run: a decision that affected a customer. Here is where the time went. ## Weeks 1–2 · Scope and data reality We spent the first fortnight doing two things: writing down the decision in one page, and opening every data source we were promised. Half of them were not what the documentation said. That discovery belongs at the start — a data contract signed in week two is worth a month later. ## Weeks 3–4 · The path to production, before the model Before any modelling, we built the deployment path end to end with a hard-coded decision: request in, decision out, logged, monitored, reversible. It scored nothing useful, but it proved the plumbing and gave every subsequent change a place to land. > Build the boring path first. A model with nowhere to go is a demo; a path with > a placeholder in it is a product waiting for its brain. ## Weeks 5–6 · The two weeks we lost We built the first scorecard against a training set that had been filtered upstream — the rejected applications were missing. Every metric looked excellent and every metric was meaningless. We caught it when the approval rate in shadow mode came out twenty points above the existing policy. The lesson was not "check your data", which everyone already knows. It was that we had no automated check comparing the shape of our training population against the live population. We added one that afternoon. It has caught two similar problems since, on other projects. ## Weeks 7–8 · Shadow mode Two weeks running alongside the incumbent policy on live traffic, deciding nothing. This is where the disagreements surface — and where the credit team stops treating the system as a threat, because they can see every case where it differs and say why. ## Weeks 9–10 · Committee and the pack The assurance pack was assembled as we went, so this was a review rather than a scramble. One round of questions, one round of changes: a tighter out-of-distribution fallback and a clearer override trail. ## Week 11 · Live, on a slice We went live on a narrow segment with a low limit, watched it for a week, then widened. Nobody remembers a cautious launch. Everybody remembers a bad one. ## What we would change - Run the population-shape check from day one, not week six. - Start shadow mode a week earlier, even with a worse model — the conversations it starts are worth more than the accuracy. - Write the override path before the scoring logic. It is the part the business actually asks about.EngineeringDeliveryUnderwritingShahaf Lavihttps://zeroevoke.com/blog/when-a-rules-engine-beats-a-model/https://zeroevoke.com/blog/when-a-rules-engine-beats-a-model/Three cases from last year where the honest recommendation was to build a rules engine and a good interface instead of a model.Fri, 03 Jul 2026 00:00:00 GMTWe are hired to build intelligent systems, so there is a commercial incentive to find a modelling problem in every brief. Resisting it is the fastest way to build trust — and often the fastest way to a result. ## Case one · The policy was the problem A client wanted a model to improve approval rates. The existing policy had forty-one rules, nine of which contradicted each other and four of which had been added for a product discontinued in 2021. We mapped the rules, removed the dead ones, and approval rates moved more than any model would have delivered in the first year. Total effort: three weeks. > If nobody can state the current policy in one page, a model will not fix it. It > will encode the confusion and make it harder to see. ## Case two · Not enough outcomes A specialist insurer had 900 claims a year in the segment they wanted to automate, with an eighteen-month outcome horizon. That is not a training set; it is an anecdote. We built a deterministic triage with explicit thresholds and a review queue, and instrumented it so that in three years there will be enough clean data to revisit the question honestly. ## Case three · The regulator would never accept it The decision fell in a category where the client's regulator expects a fully specified basis. A model could have been made explainable, but the approval path would have consumed a year. The rules engine shipped in eight weeks and freed the team to apply models where nobody was watching so closely — pricing analysis and portfolio monitoring. ## The test we use - Can you state the current policy on one page? If not, fix that first. - Do you have thousands of clean outcomes with a horizon shorter than the business cycle? If not, defer. - Would the approval path take longer than the payback period? If so, choose the boring option. - Is the value in the decision, or in seeing the decision? If it is the latter, you need reporting, not a model. None of this is an argument against models. It is an argument for earning the right to use one — and for saying so early, when it still costs a conversation rather than a quarter.OpinionRiskAnalyticsShahaf Lavi