AI Engineering for Enterprise Java

Your domain model, transactions, permissions and audit trails already live in Java. Building a parallel Python stack next to them duplicates that logic and creates a second security perimeter. We integrate AI on the JVM, inside your architecture: the model proposes, your domain services decide. A proposal is a typed Java object, validated like any other input before anything touches your data.

The three main JVM frameworks are not interchangeable, and we choose per use case.

• Spring AI is the official Spring project for AI engineering. It offers a portable ChatClient with advisors, support for many model providers and vector stores, MCP clients and servers, and Micrometer observability. For a Spring Boot application with a well-defined AI feature, it is usually the natural choice.
• LangChain4j is an independent Java library, not a port of the Python LangChain project. It works with Quarkus, Spring Boot, Helidon and Micronaut and provides declarative AI Services, tools, RAG and guardrails. Its core is stable; some advanced modules are still published as beta or experimental, which we take into account.
• Embabel is an agent framework created by Rod Johnson, the creator of Spring, and built on Spring AI. It plans the sequence of steps over typed domain objects with a planning algorithm (GOAP) that does not rely on the language model, validates outputs with Bean Validation and supports human-in-the-loop steps. It suits multi-step processes over a rich domain model. It reached version 1.0 in 2026, so we manage it as a young dependency.

When a process is deterministic and known in advance, we often recommend no agent at all: an explicit workflow with targeted model calls is simpler to test and operate.

Retrieval-augmented generation over your documents, with access control enforced at retrieval time so users only get answers from content they are allowed to see. Tool calling that exposes existing domain services with least privilege, read-only tools separated from those that change data. The Model Context Protocol where a standard interface between models and tools helps. Structured outputs mapped to Java records. Agentic workflows only where the next step genuinely depends on the data.

We design against the risks catalogued in the OWASP Top 10 for LLM Applications: prompt injection, sensitive information disclosure, excessive agency, improper output handling. Untrusted content such as emails, PDFs and web pages is treated as data, secrets never enter the model context, and irreversible or regulated actions require explicit, recorded human approval. For sensitive data we minimize and pseudonymize before any model call, and use local or self-hosted models, or Swiss and EU hosting verified case by case. We know regulatory references such as Swiss data protection law, FINMA's guidance on AI governance and the EU AI Act, and we design with them in mind, without claiming that technology alone makes a system compliant.

Every use case gets an evaluation dataset built from real, anonymized cases, run in CI whenever a prompt, model or framework version changes: deterministic checks first, then model-based evaluation, then human review of samples. Prompts are versioned artefacts and model identifiers are pinned. Token usage, latency and cost are exported as metrics per use case, small or local models handle classification and extraction, and budgets stop runaway processes. Prompt and completion content is not logged unless you decide otherwise.

AI tools help us understand large legacy codebases faster, draft characterization tests and accelerate repetitive migration work, combined with deterministic tools such as OpenRewrite. Every change is reviewed and tested by an engineer: AI speeds up the work, it does not take responsibility for it.