Orquestador de IA Agéntica para Procesamiento de Documentos Médicos en AWS

El problema fundamental que resuelve SmartProminence AI Orchestrator es la gestión de la complejidad y el coste asociados a la implementación de múltiples sistemas de inteligencia artificial, especialmente en entornos altamente regulados como el sanitario. Tradicionalmente, cada caso de uso de IA requiere su propia infraestructura, certificaciones de cumplimiento y controles de seguridad, lo que lleva a una fragmentación insostenible y ciclos de desarrollo prolongados. La solución aborda esto mediante un marco agéntico unificado que centraliza la infraestructura de cumplimiento y seguridad, permitiendo el despliegue rápido y escalable de flujos de trabajo de IA configurables.

La necesidad de esta arquitectura surge de la creciente demanda de automatización en el procesamiento de grandes volúmenes de documentos médicos no estructurados (notas clínicas, resultados de laboratorio, etc.) frente a criterios de políticas estructuradas. La intervención manual es costosa y lenta, especialmente para profesionales con altas tarifas horarias. Un sistema que pueda automatizar la investigación y el resumen de evidencia, manteniendo la trazabilidad y el cumplimiento, es crucial para la eficiencia operativa y la reducción de costes en el sector sanitario.

Este enfoque se alinea con principios de diseño de sistemas distribuidos que buscan desacoplar la lógica de negocio de la infraestructura subyacente. Al abstraer la complejidad del cumplimiento y la orquestación, los equipos pueden centrarse en la lógica de los agentes y el diseño de prompts, acelerando la innovación sin comprometer la seguridad o la escalabilidad.

Arquitectura del Sistema

La arquitectura de SmartProminence AI Orchestrator se basa en un patrón controlador-agente, implementado de forma stateless y event-driven. El "Agent Orchestration Core", construido con Spring Boot y ejecutándose en AWS Fargate, actúa como el punto central, exponiendo una API REST para la gestión de trabajos, flujos de trabajo, proxy de LLM y gestión de tokens. Este core es el único componente con acceso directo a la base de datos (Amazon RDS para MySQL 8.4), lo que impone límites estrictos de acceso a los datos.

La comunicación entre el core, los controladores y los agentes se realiza a través de colas de mensajes de Amazon SQS. Cuando llega un trabajo, el "Workflow Engine Controller" carga la definición del flujo de trabajo, resuelve las dependencias de los pasos en un Directed Acyclic Graph (DAG) utilizando el algoritmo de Kahn, y pre-crea ejecuciones de pasos en estado WAITING. Utiliza expresiones condicionales (Spring Expression Language - SpEL) para decidir qué pasos ejecutar o saltar, y luego despacha agentes capa por capa. Los pasos a la misma profundidad se ejecutan en paralelo, y el controlador sondea su finalización antes de avanzar a la siguiente profundidad. Cada mensaje SQS está asegurado con un "capability token" generado por AWS KMS, con un ámbito limitado a los datos de esa operación específica.

Cada agente ejecuta un pipeline estandarizado que incluye: "input binding" (resolución de expresiones para recopilar resultados de pasos anteriores), procesamiento de visión opcional para documentos escaneados, "prompt assembly" con contexto enriquecido, invocación de LLM a Amazon Bedrock (utilizando modelos como Claude), y post-procesamiento para extracción de campos, coerción de tipos y salida estructurada. Para cargas de trabajo paralelas dentro de un solo paso, los agentes utilizan "Java virtual threads". Los artefactos de trabajo, documentos y configuraciones de flujo de trabajo inmutables se almacenan en Amazon S3, cifrados con claves AWS KMS específicas del cliente para aislamiento multi-tenant. Amazon Cognito se utiliza para la autenticación OAuth2/JWT para el acceso a la API.

// Example conceptual snippet, actual implementation would involve more context
class AgentTaskProcessor {
    void processMultiPageDocument(List<Page> pages) {
        ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor();
        List<Future<PageResult>> futures = new ArrayList<>();
        for (Page page : pages) {
            futures.add(executor.submit(() -> processSinglePage(page)));
        }
        // Collect results
        for (Future<PageResult> future : futures) {
            try {
                PageResult result = future.get();
                // Aggregate results
            } catch (InterruptedException | ExecutionException e) {
                // Handle error
            }
        }
        executor.shutdown();
    }

    private PageResult processSinglePage(Page page) {
        // Logic for LLM invocation, post-processing for a single page
        return new PageResult();
    }
}

Fundamentos Teóricos

La resolución de dependencias de pasos en un Directed Acyclic Graph (DAG) mediante el algoritmo de Kahn es un concepto fundamental en la teoría de grafos y la planificación de tareas. El algoritmo de Kahn, propuesto por Arthur B. Kahn en 1962, proporciona un método para realizar una ordenación topológica de un DAG, lo que es esencial para determinar el orden correcto de ejecución de tareas con dependencias. En este contexto, permite al Workflow Engine Controller identificar qué pasos pueden ejecutarse en paralelo y cuándo se cumplen las precondiciones para avanzar a la siguiente etapa del flujo de trabajo.

El uso de un patrón controlador-agente y la comunicación asíncrona a través de colas de mensajes se alinea con los principios de los sistemas distribuidos y la arquitectura orientada a eventos, que buscan desacoplar componentes para mejorar la escalabilidad, la resiliencia y la mantenibilidad. Estos principios han sido explorados extensamente en la literatura académica sobre sistemas distribuidos, donde la gestión de estado, la consistencia y la tolerancia a fallos son desafíos centrales. La implementación de "capability tokens" para el control de acceso de menor privilegio es una aplicación práctica de los principios de seguridad de la información, buscando minimizar la superficie de ataque y limitar el impacto de un componente comprometido, un concepto que se remonta a los trabajos de Butler Lampson sobre seguridad en sistemas operativos y distribuidos.