Desarrollar IA en Java con Spring AI: por qué Spring Modulith es la pieza que falta

El argumento de "para IA hay que estar en Python" tiene sentido cuando se entrenan modelos, se hace experimentación o se manejan datasets en notebooks. Pero la mayoría de proyectos empresariales de IA no entrenan modelos: los consumen. Lo que hay que construir es la integración entre un modelo (alojado en OpenAI, Anthropic, Azure, Vertex u Ollama on-prem) y la lógica de negocio crítica de la empresa. Y esa lógica, en muchos sectores, lleva veinte años escrita en Java.

Forzar a esos equipos a reescribir su stack para incorporar IA es un cálculo que rara vez sale a cuenta. Implica duplicar capacidades — autenticación, transacciones, observabilidad, despliegue, compliance — que ya están resueltas en el ecosistema Spring. La opción razonable es traer la IA al lugar donde vive el dominio, no construir un servicio Python paralelo al que el monolito Java tenga que llamar por HTTP cada vez que necesita razonar.

Spring AI es la respuesta del equipo de Spring a un hueco evidente: ofrecer las mismas primitivas que LangChain, LlamaIndex o los SDK oficiales de los proveedores ofrecen en Python, pero con el modelo de programación Spring. Su valor no está en "hacer cosas que Python no puede". Está en que un equipo Spring puede integrar un modelo de lenguaje sin salir de los patrones que ya domina: inyección de dependencias, autoconfiguración por properties, beans, perfiles, observabilidad con Micrometer, tests con Spring Boot Test.

El cambio mental al adoptarlo es pequeño. Se añade una dependencia, se configura el provider en application.yml, se inyecta un ChatClient y se llama. La complejidad real (prompts, evaluación, retrieval, guardrails) sigue ahí, pero el ruido de fontanería desaparece. En organizaciones donde la disciplina de Spring ya está consolidada, eso reduce drásticamente la fricción para llevar la IA a producción.

Más allá del hello-world de un ChatClient, las piezas que marcan la diferencia cuando el proyecto crece son estas:

• ChatClient unificado: cambiar de proveedor (OpenAI, Anthropic, Azure, Vertex, Ollama, Bedrock) se resuelve modificando configuración, no código.
• VectorStore con conectores nativos a PGVector, Qdrant, Pinecone, Elasticsearch, Redis, Chroma y otros. Permite construir RAG sin atarse a una base vectorial concreta.
• Tools / function calling expresadas como beans Spring: el modelo puede invocar lógica de tu aplicación con los mismos permisos y trazabilidad que cualquier otro componente.
• Structured output a clases Java tipadas, sin parsing manual de JSON ni lidiar con respuestas mal formateadas.
• Advisors para resolver cross-cutting concerns — RAG, logging, retries, guardrails, rate limiting — siguiendo un patrón familiar para cualquier equipo Spring.
• Observabilidad nativa con Micrometer: métricas de tokens, latencia y coste expuestas al stack de observabilidad existente (Prometheus, Datadog, etc.).
• Soporte de MCP (Model Context Protocol) para que los agentes interactúen con sistemas externos siguiendo un estándar abierto, sin reinventar la integración cada vez.

Un sistema de IA empresarial nunca se queda en "un endpoint que llama a un modelo". A los pocos sprints aparecen capas que conviven mal entre sí: ingesta de documentos, indexación vectorial, prompt templates por caso de uso, tools que invocan APIs internas, evaluadores con golden datasets, audit trail de cada interacción, métricas de coste, guardrails para limitar PII, multi-tenancy. Cada nuevo caso de uso añade piezas que tocan a las anteriores.

Sin estructura, todo eso convive en los mismos paquetes. Un cambio en el retriever revienta los tests del chat. Una mejora en el evaluator obliga a tocar la capa de observabilidad. La velocidad cae, las regresiones aumentan y aparece la pregunta clásica: "¿no deberíamos partirlo en microservicios?". A menudo la respuesta correcta no es romper el monolito, sino disciplinarlo.

Spring Modulith es la apuesta del ecosistema Spring por el monolito modular. La idea es simple: dejar de tratar los paquetes Java como espacios de nombres arbitrarios y empezar a tratarlos como módulos con API pública, internals encapsulados y dependencias explícitas. La parte clave es que esa disciplina se verifica automáticamente en tests — no depende de la buena voluntad del equipo ni de un revisor de PR atento.

En un proyecto de IA, esa disciplina pesa el doble. Cada módulo (ingesta, retrieval, chat, evaluación, audit, observabilidad, gobernanza) tiene su propio ciclo de cambio, su propio dataset de pruebas y, a menudo, sus propios proveedores externos. Mantenerlos separados, comunicando vía eventos de Spring, permite añadir nuevos consumidores — un nuevo evaluator, un nuevo dashboard, una nueva alerta — sin tocar el productor. Y, si algún módulo crece hasta justificar su propio despliegue, extraerlo a un servicio independiente cuesta una fracción de lo que costaría arrancarlo de un monolito sin estructura.

Cuando aplicamos este stack en un proyecto real, la división de módulos suele parecerse a esta:

• ingestion: lectura de fuentes (SharePoint, S3, base de datos), limpieza y troceado de documentos. Publica DocumentIngestedEvent al terminar.
• retrieval: construcción del índice vectorial y API de búsqueda semántica. Reacciona a DocumentIngestedEvent y expone un servicio de query a otros módulos.
• chat: ChatClient, prompt templates, advisors de RAG y de guardrails, tools. Es el único módulo que conoce la API del LLM.
• evaluation: golden datasets, ejecución periódica de evals, alertas si alguna métrica cae. Independiente del flujo de producción.
• audit: persistencia inmutable de cada interacción (prompt, respuesta, fuentes citadas, usuario, coste). Crítico para compliance y para reentrenar prompts con datos reales.
• observability: métricas de tokens, latencia y coste por usuario y por caso de uso, conectadas a Micrometer y al dashboard corporativo.
• governance: políticas de uso, permisos por rol, rate limits, detección de PII en entrada y salida del modelo.

Los equipos que adoptan Spring AI + Modulith con éxito comparten una serie de hábitos. Definen los módulos antes de empezar a desarrollar, no después. Tratan la observabilidad de coste como una métrica de producto, no como un detalle de operaciones. Persisten los eventos críticos para que el sistema sobreviva a reinicios y caídas. Y mantienen un dataset de evaluación propio: sin él, las regresiones de calidad aparecen en silencio y el sistema se degrada sin que nadie lo note hasta que un cliente se queja.

Sobre cuándo apostar por este stack: tiene sentido si la organización ya opera Spring Boot en producción y quiere integrar IA donde vive la lógica crítica del negocio, especialmente en sectores con compliance estricto (banca, salud, sector público, seguros). No lo tiene si el equipo es 100% data science centrado en experimentación — ahí Python sigue siendo el camino corto. Tampoco compensa para prototipos de fin de semana, donde la disciplina arquitectónica es overkill. La regla práctica: este stack brilla cuando el sistema de IA debe convivir años con el resto del software corporativo, no cuando se trata de validar una idea.