Amsterdam JUG Meetup at ING
Details
Join in with the latest Amsterdam JUG Meetup at ING, Bijlmerdreef 106, 1102 CT Amsterdam.
Agenda:
17:30: Doors open (and food)
18:00 - 18:45 - Talk 1: "When Silence Becomes a Security Vulnerability" -- Sarah Gruneisen
18:45 - 19:30 - Talk 2: "AI in Java for the Financial Industry" -- Zoran Sevarac
19:30 - 20:15 - Talk 3: "Building Durable AI Workflows for Regulated Work" -- Hossein Kazemi
20:15 - 21:00 - Talk 4: "The LLM Pipeline That Survived Two Years in Production" -- Iudzhin Uord
Abstracts:
Talk 1: "When Silence Becomes a Security Vulnerability" -- Sarah Gruneisen
Security conversations often begin with technical controls: secure pipelines, dependency scanning, credentials, guardrails, monitoring, and incident response.
But a vulnerability may emerge long before any tool can detect it, in the moment someone notices a weak signal and decides that speaking feels too dangerous.
Drawing on more than two decades in software engineering and engineering leadership, Sarah Gruneisen explores the human conditions that determine whether critical information reaches the system at all. She introduces a five-layer security model built from the foundation upward:
- Human safety
- Courageous communication
- Technical controls
- Detection, response, and recovery
- Learning and governance
Through stories, practical examples, and insights from leadership psychology, Sarah reveals how hierarchy, fear, belonging, nervous-system responses, and team culture shape security outcomes.
This session does not replace technical security expertise. It exposes what technical controls depend upon: people who can question assumptions, disclose mistakes, challenge authority, and say, “I think we missed something,” before a weak signal becomes an incident.
Participants will leave with a practical framework for helping truth travel through their teams and for making human safety part of the security architecture.
Talk 2: "AI in Java for the Financial Industry" -- Zoran Sevarac
Java runs much of the financial industry, and it's increasingly where AI belongs too. Fraud detection, risk scoring and real-time decisions need models that are accurate, but also fast, predictable, secure and easy to plug into existing systems.
Continuing the conversation from the recent Amsterdam JUG meetup at Mollie, this session shows how modern Java handles AI workloads without leaving the JVM. We'll cover GPU acceleration with the Foreign Function & Memory API, CPU optimization with the Vector API, and running models efficiently in production.
Using a fraud detection example, we'll look at how teams can build high-throughput, low-latency AI on the Java skills and infrastructure they already have.
Talk 3: "Building Durable AI Workflows for Regulated Work" -- Hossein Kazemi
AI demonstrations follow the happy path. Production systems cannot. Model providers time out, tools fail, processes restart, people take days to respond, and the application changes while work is still in progress.
This talk treats AI workflows as long-running distributed systems. The running example is an AI-assisted client intake and suitability review for a wealth-management firm: the system gathers what it needs from an advisor, applies a versioned set of regulatory rules, each traceable to the article it rests on, drafts an explanation, checks that explanation against the evidence, and waits for a human to approve it.
Along the way, we will fail a model call and watch it retry, stop the process mid-review and resume without losing completed work, pause for a decision that arrives days later, and inspect the full execution history afterwards.
Durable execution does not remove every engineering problem. Retried activities must be idempotent, sensitive payloads must be protected, and long-running workflows must evolve safely across deployments. A replayable workflow does not make model output deterministic, and its execution history is not automatically a compliant audit record. In this system, the model drafts and checks, but a human makes the final determination. That boundary is enforced by the workflow itself.
The same patterns apply beyond financial services, including software factories in which coding agents plan changes, run tests, respond to findings, and wait for developer approval. The central question is not which model to use, but how to design the system around it.
Talk 4: "The LLM Pipeline That Survived Two Years in Production" -- Iudzhin Uord
Two years ago, we started extracting financial data from Finnish annual reports with a single LLM call: PDF in, JSON out. It worked on the first report and fell apart on real ones.
I'll talk about what we built around that call to make it reliable: messy files, wrong numbers that look right, deprecated models, and what benchmarking taught us.