El dilema del desarrollador de Java: Parte 3 – O’Reilly

En el primer artículo analizamos el dilema del desarrollador de Java: la brecha entre los prototipos llamativos y la realidad de los sistemas de producción empresarial. En el segundo artículo exploramos por qué se necesitan nuevos tipos de aplicaciones y cómo la IA cambia la forma del software empresarial. Este artículo se centra en lo que significan esos cambios para la arquitectura. Si las aplicaciones se ven diferentes, la forma en que las estructuramos también tiene que cambiar.

La pila empresarial tradicional de Java

Las aplicaciones empresariales Java siempre han tenido que ver con la estructura. Un sistema típico se construye sobre un conjunto de capas. En la base está la persistencia, a menudo con JPA o JDBC. La lógica empresarial va por encima de eso, haciendo cumplir reglas y procesos. En la parte superior se encuentran REST o puntos finales de mensajería que exponen los servicios al mundo exterior. Preocupaciones transversales como las transacciones, la seguridad y la observabilidad atraviesan la pila. Este modelo ha demostrado ser duradero. Ha llevado Java desde los primeros días de los servlets a marcos modernos como cuarcus, Bota de primaveray micronauta.

El éxito de esta arquitectura proviene de la claridad. Cada capa tiene una responsabilidad clara. La aplicación es predecible y fácil de mantener porque usted sabe dónde agregar lógica, dónde aplicar políticas y dónde conectar la supervisión. Agregar IA no elimina estas capas. Pero sí añade otros nuevos, porque el comportamiento de la IA no encaja en los claros supuestos del software determinista.

Nuevas capas en aplicaciones impulsadas por IA

La IA cambia la arquitectura al introducir capas que nunca existieron en los sistemas deterministas. Tres de los más importantes son la validación difusa, las barreras de seguridad sensibles al contexto y la observabilidad del comportamiento del modelo. En la práctica encontrará aún más componentes, pero la validación y la observabilidad son la base que hace que la IA sea segura en producción.

Validación y barandillas

Las aplicaciones Java tradicionales suponen que las entradas se pueden validar. Verifica si un número está dentro del rango, si una cadena no está vacía o si una solicitud coincide con un esquema. Una vez validado, lo procesa de forma determinista. Con los resultados de la IA, esta suposición ya no se cumple. Un modelo puede generar texto que parezca correcto pero que sea engañoso, incompleto o dañino. El sistema no puede confiar ciegamente en él.

Aquí es donde entran la validación y las barreras de seguridad. Forman una nueva capa arquitectónica entre el modelo y el resto de la aplicación. Las barandillas pueden adoptar diferentes formas:

• Validación de esquema: Si espera un objeto JSON con tres campos, debe verificar que la salida del modelo coincida con ese esquema. Un campo faltante o con formato incorrecto debe tratarse como un error.
• Verificaciones de políticas: Si su dominio prohíbe ciertos resultados, como exponer datos confidenciales, devolver identificadores personales o generar contenido ofensivo, las políticas deben filtrarlos.
• Aplicación de rango y tipo: Si el modelo produce una puntuación numérica, debe confirmar que la puntuación es válida antes de pasarla a su lógica empresarial.

Las empresas ya saben lo que sucede cuando falta la validación. La inyección SQL, las secuencias de comandos entre sitios y otras vulnerabilidades nos han enseñado que las entradas no controladas son peligrosas. Las salidas de IA son otro tipo de entrada que no es confiable, incluso si provienen del interior de su propio sistema. Tratarlos con sospecha es un requisito.

En Java, esta capa se puede construir con herramientas familiares. Puede escribir anotaciones de validación de beans, comprobaciones de esquemas o incluso interceptores CDI personalizados que se ejecuten después de cada llamada de IA. La parte importante es arquitectónica: la validación no debe ocultarse en métodos de utilidad. Tiene que ser una capa visible y explícita en la pila para que pueda mantenerse, evolucionar y probarse rigurosamente a lo largo del tiempo.

Observabilidad

La observabilidad siempre ha sido fundamental en los sistemas empresariales. Los registros, métricas y seguimientos nos permiten comprender cómo se comportan las aplicaciones en producción. Con la IA, la observabilidad se vuelve aún más importante porque el comportamiento no es determinista. Un modelo podría dar mañana respuestas diferentes a las que ofrece hoy. Sin visibilidad, no se puede explicar ni depurar por qué.

La observabilidad para la IA significa más que registrar un resultado. Requiere:

• Seguimiento de indicaciones y respuestas: Capturar lo que se envió al modelo y lo que regresó, idealmente con identificadores que los vinculen con la solicitud original.
• Contexto de grabación: Almacenar los datos recuperados de bases de datos vectoriales u otras fuentes para saber qué influyó en la respuesta del modelo.
• Costo de seguimiento y latencia: Monitorear la frecuencia con la que se llaman los modelos, cuánto tiempo tardan y cuánto cuestan.
• Notificar deriva: Identificar cuándo la calidad de las respuestas cambia con el tiempo, lo que puede indicar una actualización del modelo o un rendimiento degradado en datos específicos.

Para los desarrolladores de Java, esto se corresponde con la práctica existente. ya nos integramos OpenTelemetríamarcos de registro estructurados y exportadores de métricas como Micrómetro. La diferencia es que ahora necesitamos aplicar esas herramientas a señales específicas de IA. Un mensaje es como un evento de entrada. Una respuesta modelo es como una dependencia posterior. La observabilidad se convierte en una capa adicional que atraviesa la pila y captura el proceso de razonamiento en sí.

Considere un Aplicación Quarkus que se integra con OpenTelemetry. Puede crear intervalos para cada llamada de IA; agregue atributos para el nombre del modelo, recuento de tokens, latencia y aciertos de caché; y exportar esas métricas a Grafana u otro sistema de monitoreo. Esto hace que el comportamiento de la IA sea visible en los mismos paneles que ya utiliza su equipo de operaciones.

Mapeo de nuevas capas a prácticas familiares

La idea clave es que estas nuevas capas no reemplazan a las antiguas. Los extienden. La inyección de dependencia todavía funciona. Debe inyectar un componente de barrera en un servicio de la misma manera que inyecta un validador o registrador. Las bibliotecas de tolerancia a fallos como MicroProfile Fault Tolerance o Resilience4j siguen siendo útiles. Puede envolver llamadas de IA con tiempos de espera, reintentos y disyuntores. Los marcos de observabilidad como Micrometer y OpenTelemetry siguen siendo relevantes. Simplemente les diriges hacia nuevas señales.

Al tratar la validación y la observabilidad como capas, no como parches ad hoc, se mantiene la misma disciplina arquitectónica que siempre ha definido Java empresarial. Esa disciplina es lo que mantiene los sistemas mantenibles cuando crecen y evolucionan. Los equipos saben dónde buscar cuando algo falla y saben cómo ampliar la arquitectura sin introducir trucos frágiles.

Un flujo de ejemplo

Imagine un punto final REST que responda las preguntas de los clientes. El flujo se ve así:

1. La solicitud llega a la capa REST.
2. Un generador de contexto recupera documentos relevantes de un almacén de vectores.
3. El mensaje se ensambla y envía a un modelo local o remoto.
4. El resultado pasa a través de una capa de barandilla que valida la estructura y el contenido.
5. Los ganchos de observabilidad registran la indicación, el contexto y la respuesta para su posterior análisis.
6. El resultado validado fluye hacia la lógica empresarial y se devuelve al cliente.

Este flujo tiene capas claras. Cada uno puede evolucionar de forma independiente. Puede cambiar el almacén de vectores, actualizar el modelo o ajustar las barandillas sin reescribir todo el sistema. Esa modularidad es exactamente lo que las arquitecturas Java empresariales siempre han valorado.

Un ejemplo concreto podría ser el uso de LangChain4j en Quarkus. Usted define una interfaz de servicio de IA, la anota con el enlace del modelo y la inyecta en su clase de recurso. Alrededor de ese servicio, agrega un interceptor de barandilla que aplica un esquema utilizando Jackson. Agrega un intervalo de OpenTelemetry que registra el mensaje y los tokens utilizados. Nada de esto requiere abandonar la disciplina Java. Es el mismo pensamiento que siempre hemos usado, ahora aplicado a la IA.

Implicaciones para los arquitectos

Para los arquitectos, la principal implicación es que la IA no elimina la necesidad de estructura. En todo caso, lo aumenta. Sin límites claros, la IA se convierte en una caja negra en medio del sistema. Eso no es aceptable en un entorno empresarial. Al definir las barreras de seguridad y la observabilidad como capas explícitas, los componentes de IA son tan manejables como cualquier otra parte de la pila.

Esto es lo que significa evaluación en este contexto: medir sistemáticamente cómo se comporta un componente de IA, utilizando pruebas y seguimiento que van más allá de los controles de corrección tradicionales. En lugar de esperar resultados exactos, las evaluaciones analizan la estructura, los límites, la relevancia y el cumplimiento. Combinan pruebas automatizadas, indicaciones seleccionadas y, a veces, revisión humana para generar confianza en que un sistema se comporta según lo previsto. En entornos empresariales, la evaluación se convierte en una actividad recurrente en lugar de un paso de validación único.

La evaluación en sí misma se convierte en una preocupación arquitectónica que va más allá de los propios modelos. Hamel Husain describe la evaluación como una Sistema de primera clase, no un complemento.. Para los desarrolladores de Java, esto significa integrar la evaluación en CI/CD, tal como lo son las pruebas unitarias y de integración. La evaluación continua de indicaciones, recuperación y resultados se convierte en parte del proceso de implementación. Esto amplía lo que ya hacemos con los conjuntos de pruebas de integración.

Este enfoque también ayuda con las habilidades. Los equipos ya saben cómo pensar en términos de capas, servicios y preocupaciones transversales. Al enmarcar la integración de la IA de la misma manera, se reduce la barrera para la adopción. Los desarrolladores pueden aplicar prácticas familiares a comportamientos desconocidos. Esto es fundamental para la dotación de personal. Las empresas no deberían depender de un pequeño grupo de especialistas en IA. Necesitan grandes equipos de desarrolladores de Java que puedan aplicar sus habilidades existentes con solo una capacitación moderada.

También hay un aspecto de gobernanza. Cuando los reguladores o auditores preguntan cómo funciona su sistema de inteligencia artificial, debe mostrar más que un diagrama con un cuadro de “llame a LLM aquí”. Debe mostrar la capa de validación que verifica los resultados, las barreras de seguridad que hacen cumplir las políticas y la observabilidad que registra las decisiones. Esto es lo que hace que la IA deje de ser un experimento para convertirse en un sistema de producción en el que se puede confiar.

Pensando en el futuro

Los cambios arquitectónicos descritos aquí son sólo el comienzo. A medida que madure la adopción de la IA, surgirán más capas. Veremos capas de almacenamiento en caché especializadas y por usuario para controlar los costos, un control de acceso detallado para limitar quién puede usar qué modelos y nuevas formas de pruebas para verificar el comportamiento. Pero la lección central es clara: la IA requiere que agreguemos estructura, no que la eliminemos.

La historia de Java nos da confianza. Ya hemos transitado cambios de monolitos a sistemas distribuidos, de programación síncrona a reactiva y de lo local a la nube. Cada turno agregó capas y patrones. Cada vez, el ecosistema se adaptó. La llegada de la IA no es diferente. Es un paso más en el mismo viaje.

Para los desarrolladores de Java, el desafío no es desechar lo que sabemos sino ampliarlo. El cambio es real, pero no extraño. La historia de Java de arquitecturas en capas, inyección de dependencias y servicios transversales nos brinda las herramientas para manejarlo. El resultado no son prototipos ni demostraciones únicas, sino aplicaciones confiables, auditables y listas para los largos ciclos de vida que exigen las empresas.

En nuestro libro, IA aplicada al desarrollo empresarial de Javaexploramos estos cambios arquitectónicos en profundidad con ejemplos y patrones concretos. Desde canales de recuperación con Docling hasta pruebas de seguridad e integración de observabilidad, mostramos cómo los desarrolladores de Java pueden tomar las ideas descritas aquí y convertirlas en sistemas listos para producción.