La IA toma
forma.

Qué servicio presta al afiliado

SARA convierte la búsqueda estática del Directorio Médico en una conversación dentro de la Oficina Virtual web y las aplicaciones Android e iOS. El afiliado puede escribir con sus propias palabras, dictar un audio o adjuntar una imagen de una orden médica. El sistema interpreta la intención y orienta la búsqueda según el plan, la cartilla y la ciudad de la sesión, sin exigir que la persona conozca el nombre técnico exacto de una especialidad.

Cubre especialidades, servicios y procedimientos, prestadores por nombre, urgencias médicas y odontológicas, preguntas frecuentes y la línea odontológica SAO. El resultado combina un mensaje con tarjetas de prestadores que pueden incluir dirección, teléfonos, WhatsApp y coordenadas. Es informativo: no diagnostica, agenda, tramita autorizaciones ni ofrece contactar al médico. La ciudad procede de la aplicación o de su confirmación en conversación, no de geolocalización.

Recepción y ejecución son funciones distintas

Todos los canales pasan por el proxy corporativo msc-back antes de llegar a n8n. n8n-main recibe el webhook y encola el trabajo en Redis; los workers ejecutan los workflows y sus runners procesan código JavaScript o Python de forma separada. El modo cola desacopla la entrada de solicitudes de la ejecución. La plataforma vigente usa Docker Compose en el servidor de producción; no debe dibujarse Kubernetes como si ya estuviera operativo.

La cola técnica de n8n y el Redis de negocio son servicios distintos. Este último conserva contexto, resultados temporales y caché; PostgreSQL conserva el historial de chat y otra base PostgreSQL soporta los workflows y las ejecuciones de n8n. El diagrama reúne componentes para facilitar la explicación, sin convertir las ramas auxiliares en pasos obligatorios de cada consulta.

Modelos especializados y orquestación

La solución no depende de un único prompt. Un orquestador coordina preclasificadores, verificadores, planificadores y sub-workflows especializados. Puede reconocer cambios de contexto, resolver una ciudad con Meilisearch y distinguir una consulta médica de una pregunta general antes de enrutarla. El programa odontológico SAO cuenta con una planificación específica. Si falta contexto relevante, se confirma o solicita información en vez de inventarla.

La ficha documenta gpt-4.1-mini para planificación y respuesta final, gpt-4o-mini para funciones auxiliares y gpt-4o para visión y desambiguación. Gemini 2.5 Flash participa en preclasificadores y está configurado como proveedor alterno. La transcripción de audio utiliza OpenAI. El worker realiza cada llamada a los proveedores y mantiene la coordinación; un proveedor de IA no llama directamente a Qdrant ni es la fuente de los prestadores.

Qdrant convierte significado en códigos

Qdrant recupera conceptos médicos por similitud semántica en las colecciones de especialidades, servicios y preguntas frecuentes. Las descripciones enriquecidas con alias se vectorizan mediante text-embedding-3-large, con 3.072 dimensiones y distancia coseno. Así una expresión cotidiana puede corresponder a un concepto técnico aunque no coincidan literalmente las palabras. Para preguntas frecuentes se recuperan fragmentos y se redacta una respuesta fundamentada en ese contenido.

El worker solicita el embedding a OpenAI y luego consulta Qdrant por REST. Un decisor revisa la similitud y la cercanía entre candidatos; ante ambigüedad puede intervenir la desambiguación o una pregunta aclaratoria. Los códigos recuperados se combinan con filtros de sesión para consultar las APIs. Qdrant no almacena la respuesta final del directorio ni devuelve prestadores. Meilisearch resuelve ciudades de forma independiente; no es una etapa posterior de la búsqueda vectorial.

Datos y respuesta conservan su origen

El contexto inicial del afiliado y su plan procede de una API corporativa y se conserva en Redis para la sesión. Los nombres y datos de contacto de los prestadores proceden de las APIs de Coomeva, consultadas con ciudad, cartilla, plan y código de especialidad o agrupador. La búsqueda por nombre y la consulta de urgencias tienen rutas propias; no todas las intenciones requieren recuperación vectorial.

El worker consolida los resultados, solicita la redacción del mensaje y devuelve mensaje, tarjetas y ciudad activa. El retorno pasa por n8n-main y por msc-back hasta el canal. La caché evita repetir consultas cuando corresponde y los contratos de sub-workflows permiten manejar resultados de forma uniforme. La presentación distingue la interpretación lingüística, el hallazgo de conceptos y la consulta de datos para no atribuir al modelo información que obtiene de otro sistema.

Actualización del catálogo, fuera del chat

Un proceso separado mantiene el catálogo semántico. n8n inicia un pipeline Python con FastAPI y Celery, que extrae especialidades y servicios de SQL Server y compara novedades frente al maestro. Una etapa de IA con gpt-4o-mini produce alias y descripciones para mejorar la recuperación. Las colas separan las tareas de extracción y de enriquecimiento; el proceso genera CSV maestros y notifica el fin de las etapas.

El pipeline no escribe directamente en Qdrant. n8n descarga los CSV, detecta cambios mediante hashes y staging en PostgreSQL, genera embeddings y carga los puntos con identificadores deterministas. La ejecución automática está confirmada y la frecuencia diaria es la meta de actualización; no debe transformarse esa meta en un indicador medido. El enriquecimiento permite revisión manual cuando el volumen de novedades supera el umbral documentado.

Estado y evolución

El despliegue de producción se realizó en marzo de 2026 y el uso por los afiliados comenzó después, sin una fecha exacta documentada. La ventana oficial del Gantt es aproximadamente enero a abril de 2026. La configuración de producción documentada utiliza n8n 2.34.4, Redis 7, PostgreSQL 17, Qdrant 1.16.3 y Meilisearch 1.35. Las imágenes propias se distribuyen mediante Azure Container Registry.

La evolución prevista incluye actualizar configuración y modelos, mejorar audio y voz y migrar a Kubernetes. LangSmith, Flower, healthchecks y alertas de operación permiten observar partes del sistema. La evolución distingue la arquitectura vigente de las capacidades planificadas.

Componentes y responsabilidades

• Canales OVU: Web · Android · iOS
• msc-back: Proxy corporativo de entrada
• n8n-main: Recibe y encola solicitudes
• Redis · cola: Distribuye las ejecuciones
• Worker + runner: Orquesta workflows y código
• Redis · contexto: Sesión, resultados y caché
• Postgres: Historial de conversación
• Meilisearch: Resolución condicional de ciudad
• Modelos de IA: OpenAI + Gemini
• Qdrant: Conceptos, códigos y FAQ
• APIs corporativas: Afiliado, plan y prestadores
• Pipeline de catálogo: FastAPI + Celery · CSV maestros

Comunicaciones

1. Canales OVU → msc-back: Envía la consulta desde OVU o una app.
2. msc-back → n8n-main: Entrega la solicitud al webhook de n8n.
3. n8n-main → Redis · cola: Encola la ejecución.
4. Redis · cola → Worker + runner: Un worker toma el trabajo.
5. Worker + runner → Redis · contexto: Recupera el contexto; consulta historial y ciudad si corresponde.
6. Worker + runner → Modelos de IA: Normaliza y planifica; genera el embedding si la búsqueda lo necesita.
7. Worker + runner → Qdrant: Recupera candidatos y aplica la decisión de similitud y ambigüedad.
8. Worker + runner → APIs corporativas: Consulta prestadores con códigos, ciudad y filtros del plan.
9. Worker + runner → Modelos de IA: Redacta el mensaje con los resultados corporativos.
10. Worker + runner → n8n-main: Devuelve mensaje, tarjetas y ciudad activa.
11. n8n-main → msc-back: Devuelve la respuesta al proxy corporativo.
12. msc-back → Canales OVU: Entrega mensaje, tarjetas y ciudad activa al canal.

Un punto de consulta para admisiones

El Agente Centros Médicos reúne consultas operativas que antes exigían abrir libros Excel, buscar documentos en SharePoint, interpretar anexos extensos o preguntar a otras áreas. El asesor escribe en Teams como lo haría con un compañero y recibe una respuesta concreta, no una lista de archivos para revisar. Está dirigido al personal de admisiones y se utiliza con la cuenta Microsoft corporativa de los usuarios habilitados.

Sus seis áreas son agendamiento de imágenes, portafolio de prestadores, Cita Express, tarifas de colectivos, coberturas y consultas generales. Puede orientar sobre CUPS, preparación, reglas de facturación, sedes, contratos, copagos, condiciones de planes y procedimientos operativos. Los ejemplos deben ser ilustrativos y no representar pacientes o prestadores reales. La incorporación de usuarios se realiza gradualmente; no se informa el número de centros que utilizan el agente.

Copilot enruta; cada tema resuelve

La implementación combina temas de Copilot Studio con orquestación generativa activa y GPT-5 Auto. Las instrucciones convierten al agente principal en un enrutador: reconoce la intención y envía la pregunta al tema especializado, en lugar de producir una respuesta general por su cuenta. El diseño mantiene separadas las reglas, herramientas y fuentes relevantes para cada área de consulta, con una conversación común en Teams.

Cuando la intención es dudosa interviene la desambiguación. Los prompts de AI Builder clasifican, evalúan si existe información suficiente y extraen parámetros como servicio, ciudad, colectivo o CUPS. Si falta un dato, se pide aclaración antes de redirigir. Las consultas de coberturas pueden resolverse solo con conocimiento documental; las que necesitan cupos, portafolio o tarifas utilizan herramientas tabulares. No todas las preguntas recorren las mismas ramas.

Excel para registros; SharePoint para documentos

Los temas invocan flujos de Power Automate. Mediante el conector Excel Online Business, cada flujo ejecuta un Office Script escrito con TypeScript y ExcelScript sobre tablas de libros alojados en SharePoint. Los scripts admiten filtros y búsqueda difusa con alias o sinónimos y devuelven JSON compacto. Las búsquedas de portafolio combinan filtros, los relajan si no hay coincidencias y priorizan contratos activos; los resultados se limitan para mantenerlos utilizables en la conversación.

En paralelo lógico, la búsqueda generativa consulta fuentes de SharePoint y archivos publicados: manuales, banco de preguntas, glosario, CPD, anexos de coberturas y guías operativas. Cada tema tiene fuentes permitidas y descripciones de uso para orientar la recuperación. Los registros tabulares no se sustituyen por una búsqueda semántica indiscriminada: el modelo redacta sobre datos consultados y contenido recuperado. La carpeta local es material de construcción; el agente usa las fuentes publicadas.

Respuesta informativa y límites claros

La búsqueda documental no envía automáticamente su texto al asesor. Un prompt final de AI Builder recibe la pregunta, los resultados de los flujos y los hallazgos de conocimiento; después redacta la respuesta según las reglas del tema. Copilot Studio la entrega en Teams y cierra el diálogo activo. Hay manejo de inactividad y de errores para ordenar la conversación, además de mensajes de progreso mientras se realizan las consultas.

El agente no agenda, autoriza ni modifica los sistemas de operación. Los cupos de imágenes son bloques de agenda que el asesor debe reservar, no disponibilidad en tiempo real. Sistemas como Lumier, SINET, GIS o Fonosalud aparecen como contexto de los procedimientos que explica, no como integraciones transaccionales en línea. Esta frontera evita confundir la orientación entregada por IA con una acción ya ejecutada en otro sistema.

La vigencia depende de responsabilidades compartidas

El modelo de responsabilidad compartida es central: el desarrollo de IA construye el agente, configura sus temas y flujos e integra las fuentes; el área de negocio dueña del proceso mantiene actualizados los documentos y tablas de SharePoint. El agente utiliza ese contenido vigente sin que cada actualización de tarifas, cupos o manuales implique rediseñar sus instrucciones. La calidad de la respuesta depende de la calidad y actualidad de esas fuentes.

El control de calidad documentado trabaja un tema a la vez. Puede preparar matrices de casos normales, ambiguos, límites y situaciones difíciles, y evaluar precisión, proactividad, tono y formato. La operación usa la analítica nativa de Copilot Studio y reportes de usuarios; no se añadió una configuración de monitoreo en Dataverse. En la presentación se muestran responsabilidades del proceso, no contribuciones individuales ni los análisis reservados de calidad.

Estado, evolución y evidencia publicable

El piloto se desarrolló entre febrero y marzo de 2026 y la versión Centros Médicos Asesor V2 quedó disponible para uso en mayo. El Gantt oficial registra una ventana aproximada de enero a mayo. Durante la construcción se pasó de un prompt general a una arquitectura por temas, con desambiguación explícita, Office Scripts y fuentes documentales organizadas. Tras la publicación, la continuidad se concentra en actualizar el contenido de SharePoint.

La analítica publicable registra 241 sesiones de conversación y 88 % de interacción en la ventana del 11 de abril al 7 de octubre de 2026. Esa ventana no incluye la actividad del piloto y no debe interpretarse como un censo de usuarios. La adopción es gradual y los picos corresponden a incorporaciones. Son indicadores de actividad e interacción, no una medición de ahorro de tiempo.

Componentes y responsabilidades

• Asesor · Teams: Pregunta en lenguaje natural
• Copilot Studio: GPT-5 Auto · enruta la intención
• Temas especializados: Reglas y fuentes por consulta
• Desambiguación: Aclara y extrae parámetros
• Power Automate: Flujos de consulta de tablas
• Office Scripts: Excel Online · búsqueda tabular
• Excel en SharePoint: Cupos, portafolio y tarifas
• Conocimiento: SharePoint + archivos publicados
• AI Builder: Clasifica y redacta resultados
• Respuesta en Teams: Información concreta y formateada
• Área de negocio: Mantiene el contenido vigente
• Analítica nativa: Copilot Studio · seguimiento

Comunicaciones

1. Asesor · Teams → Copilot Studio: Plantea una consulta operativa en Teams.
2. Copilot Studio → Temas especializados: Reconoce la intención y selecciona el tema; aclara antes si hace falta.
3. Temas especializados → Power Automate: Envía los filtros necesarios al flujo de consulta.
4. Power Automate → Office Scripts: Ejecuta Office Script con Excel Online Business.
5. Office Scripts → Excel en SharePoint: Busca registros en la tabla publicada en SharePoint.
6. Office Scripts → Power Automate: Devuelve un resumen y resultados JSON compactos.
7. Power Automate → Temas especializados: Retorna los datos tabulares al tema.
8. Temas especializados → Conocimiento: Consulta las fuentes documentales permitidas para la intención.
9. Conocimiento → Temas especializados: Devuelve contenido recuperado sin enviarlo aún al asesor.
10. Temas especializados → AI Builder: Combina pregunta, salida de flujos y contenido documental.
11. AI Builder → Respuesta en Teams: Redacta la respuesta con las reglas del tema.
12. Respuesta en Teams → Asesor · Teams: Entrega información concreta en Teams; la operación sigue siendo humana.

Redactar sin decidir el caso

El Agente de Respuestas PQR ayuda a los analistas de Experiencia de Servicio y Voz del Usuario a redactar cartas de peticiones, quejas y reclamos. El caso, la decisión y el motivo los aporta el analista. La herramienta transforma esa información en una respuesta comprensible y empática; no decide autorizaciones, coberturas ni el resultado de la solicitud.

La conversación ocurre en Teams, en un chat uno a uno. El analista puede pedir una carta nueva, revisar un borrador, consultar una regla o solicitar orientación sobre qué plantilla usar. El resultado queda listo para copiar, pero siempre pasa por revisión humana antes del envío.

Cuatro formas de ayudar

Al redactar, el agente utiliza la tipología del caso para buscar la carta preforma adecuada. Al revisar, ajusta el borrador y explica los cambios realizados. Ante una duda, responde de forma breve citando la plantilla o regla pertinente. Cuando el usuario no sabe por dónde empezar, orienta sobre la plantilla aplicable.

Si faltan datos esenciales, devuelve preguntas numeradas antes de escribir. Si falta un dato accesorio, deja un marcador que el analista debe completar. Esa diferencia evita convertir información ausente en un hecho afirmado. La petición, la decisión y su motivo deben conservarse en la carta final.

Plantillas y guías con papeles diferentes

SharePoint reúne diecisiete cartas preforma y cuatro documentos de reglas: guía de estilo, guía de canales y dos formaciones de escritura. Las preformas definen la estructura de cada tipo de respuesta; las guías aportan el estándar de lenguaje y comunicación que debe aplicarse a todas las cartas.

Los hechos provienen del caso del analista. El estilo y los canales siguen las guías, mientras los plazos, requisitos y coberturas se sustentan en la plantilla pertinente. El agente utiliza un trato de usted, evita tecnicismos innecesarios y organiza la respuesta punto por punto. El área de negocio mantiene el contenido en SharePoint.

De la consulta a la carta

Copilot Studio utiliza GPT-5.5 Chat y una instrucción que delimita rol, modos, precedencia, formato y reglas de redacción. Consulta la fuente de SharePoint para recuperar la preforma y los fragmentos de las guías. No necesita que el analista abra cada archivo para componer la primera versión de la carta.

Antes de entregar, adapta la estructura, aplica los conectores aprobados y reúne los canales generales en un solo bloque final. Devuelve texto plano, no Markdown. En el modo de revisión añade un apartado de cambios realizados. Si todavía falta información esencial, la salida es una lista de preguntas, no una carta que complete el caso con supuestos.

La revisión y el envío son humanos

El analista comprueba que la carta refleje la decisión entregada, completa los marcadores y verifica destinatario y hechos. El agente no presta consejo clínico ni jurídico y no cambia el resultado del caso. La redacción asistida busca consistencia de lenguaje, no delegar en un modelo la responsabilidad de la atención.

La comunicación con el usuario final ocurre fuera del agente, a través del proceso habitual y el sistema de gestión PQR. No hay una conexión documentada que envíe automáticamente la respuesta desde Copilot Studio. En el diagrama, esa última acción pertenece al analista y debe mantenerse distinta de las comunicaciones del chat.

Estado y adopción con periodo explícito

El proyecto está completado en el Gantt y en uso. El periodo de planificación aproximado va del 27-jul al 1-ago-2026. La analítica de los treinta días entre el 8-sep y el 7-oct-2026 registra 734 sesiones y un promedio de seis usuarios activos diarios. Son sesiones y actividad diaria, no personas únicas ni cartas enviadas.

Frente al periodo anterior, las sesiones aumentaron un 139 % y los usuarios activos diarios un 100 %. Esas comparaciones deben conservar su ventana de medición. La arquitectura presentada corresponde al propósito en uso: plantillas y guías en SharePoint, redacción en Teams, revisión humana y envío fuera del agente.

Componentes y responsabilidades

• Analista PQR: Aporta decisión, revisa y envía
• Microsoft Teams: Chat uno a uno
• Copilot Studio: Redacción · GPT-5.5 Chat
• Instrucción: Rol, modos y reglas de escritura
• SharePoint: Fuente de conocimiento
• Cartas preforma: Plantilla por tipología
• Guías y formación: Estilo y canales
• Sistema PQR: Envío fuera del agente

Comunicaciones

1. Analista PQR → Microsoft Teams: Entrega destinatario, petición, decisión y motivo del caso.
2. Microsoft Teams → Copilot Studio: Pasa el caso o borrador al agente.
3. Copilot Studio → Instrucción: Comprueba si están completos los datos esenciales.
4. Copilot Studio → SharePoint: Busca la plantilla y las reglas de redacción.
5. SharePoint → Copilot Studio: Devuelve fragmentos de preformas y guías.
6. Copilot Studio → Copilot Studio: Redacta o revisa y verifica la respuesta.
7. Copilot Studio → Microsoft Teams: Entrega la carta en texto plano o preguntas pendientes.
8. Microsoft Teams → Analista PQR: Presenta el resultado para revisión.
9. Analista PQR → Sistema PQR: Revisa y envía por el proceso habitual, fuera del agente.

El procedimiento al alcance del colaborador

El Agente Jurídico centraliza las preguntas sobre contratación de Coomeva Medicina Prepagada. Antes, el colaborador buscaba la respuesta en varios documentos de SharePoint. Ahora pregunta en Teams y recibe una orientación consistente, acompañada por el nombre del documento que la sustenta.

Cubre fechas de comités, responsables por tipo de solicitud, documentos requeridos, montos de aprobación y pasos del procedimiento MP-PR-0070. Puede explicar diferencias generales, como aprobación frente a formalización, o cuándo consultar un otrosí o una renovación. No analiza un contrato particular ni emite un concepto personalizado.

Un agente deliberadamente informativo

Se eligió un patrón de consulta informativa en lugar de uno transaccional. El agente no dispara acciones, no tiene flujos de Power Automate y no utiliza prompts de AI Builder. La decisión reduce componentes y evita sumar el consumo de créditos de acciones que no se necesitan para responder estas dudas.

Teams es la interfaz y Copilot Studio organiza la conversación. El modelo documentado es GPT-5 Chat, con orquestación generativa activa. Las instrucciones definen alcance, enrutamiento y formato de respuesta. El conocimiento general del modelo está desactivado: la respuesta debe sustentarse en las fuentes autorizadas del procedimiento.

Seis fuentes, funciones distintas

La base de preguntas frecuentes se consulta primero. Después pueden intervenir cronogramas generales, distribución laboral, listas de chequeo y montos de aprobación; el procedimiento de contratación aporta el marco completo al final. Las fuentes viven en SharePoint, no como archivos independientes cargados al agente.

Cronogramas responde cuándo; distribución, quién atiende; listas de chequeo, qué documentos se necesitan; montos, qué instancia aprueba; y el procedimiento, cómo se tramita. Los documentos se reescribieron como preguntas y respuestas con reglas SI/ENTONCES para facilitar su recuperación. Cada fuente tiene una descripción que ayuda a seleccionar la información adecuada.

Una consulta, paso a paso

El colaborador envía una pregunta en Teams. Copilot Studio usa las instrucciones y las descripciones de las bases para determinar qué contenido consultar. Una pregunta sobre la instancia de aprobación se orienta a Montos; una duda de requisitos, a Listas de chequeo. La búsqueda recupera fragmentos de la fuente pertinente.

El agente resume esos fragmentos en viñetas o tablas y añade el nombre del documento. Si la consulta mezcla un concepto general con un caso particular, responde únicamente la parte general. Cuando no puede sostener una respuesta, utiliza un mensaje de reserva. No realiza la aprobación ni modifica el estado de una solicitud.

Fuentes vigentes y responsabilidad humana

El área de Contratación mantiene los documentos en SharePoint. El equipo de desarrollo construye el agente e integra esas fuentes; el área dueña del proceso actualiza su contenido. Esa separación permite que la información evolucione sin reconstruir toda la conversación y conserva una referencia reconocible para el usuario.

Los cambios del contenido pueden tardar entre cuatro y seis horas en sincronizarse. La publicación no significa que una edición de SharePoint aparezca instantáneamente. El colaborador sigue aplicando el procedimiento y la instancia competente toma las decisiones. El agente facilita la consulta; no sustituye a las personas responsables.

Estado y solución jurídica complementaria

El agente está publicado y en uso por unas diez a doce personas, según la confirmación del 7-oct-2026. El Gantt conserva un avance del 60 % y un periodo aproximado del 13-abr al 13-jun-2026. El porcentaje describe la planificación registrada; la situación funcional es que ya puede utilizarse.

Complementa a CaseLex AI dentro de la solución jurídica. El agente orienta sobre contratación desde Teams; CaseLex analiza casos y revisa contratos en una aplicación web. Es una relación de alcance y servicio al área, no una transferencia automática de conversaciones, documentos o decisiones entre los dos productos.

Componentes y responsabilidades

• Colaborador: Pregunta y aplica el proceso
• Microsoft Teams: Canal de conversación
• Copilot Studio: Agente jurídico · GPT-5 Chat
• Orquestación: Selecciona la fuente
• SharePoint: Conocimiento de contratación
• Preguntas frecuentes: Primera fuente de consulta
• Cronogramas: Comités y fechas
• Distribución laboral: Responsables por solicitud
• Listas de chequeo: Documentos requeridos
• Montos de aprobación: Topes e instancias
• Procedimiento: Proceso de contratación
• Área de Contratación: Mantiene las fuentes vigentes

Comunicaciones

1. Colaborador → Microsoft Teams: Pregunta qué instancia aprueba un tipo de contrato.
2. Microsoft Teams → Copilot Studio: Entrega el mensaje por el canal de Teams.
3. Copilot Studio → Orquestación: Interpreta la pregunta y su alcance informativo.
4. Orquestación → Montos de aprobación: Identifica la base de montos como fuente pertinente.
5. Copilot Studio → SharePoint: Busca los documentos de esa fuente.
6. SharePoint → Copilot Studio: Devuelve fragmentos del procedimiento vigente.
7. Copilot Studio → Microsoft Teams: Responde en viñetas o tabla y nombra la fuente.
8. Microsoft Teams → Colaborador: Presenta la orientación; no ejecuta la aprobación.

Dos tareas, una decisión humana

CaseLex AI apoya al área jurídica en dos recorridos distintos. En un caso individual, el abogado describe los hechos y adjunta documentos; en una revisión masiva, aplica el mismo cuestionario a varios contratos. El objetivo no es reemplazar el criterio profesional, sino organizar la primera lectura y devolver evidencia para revisar.

El caso individual entrega categoría, nivel de riesgo, normas aplicables, riesgos, posibles soluciones con su plazo y próximos pasos. Después permite profundizar, conversar sobre el caso y sus anexos y registrar avances en una bitácora. El abogado interpreta esos resultados y decide qué actuación corresponde.

Del contrato a la matriz

El usuario crea un cuestionario y puede reutilizarlo como plantilla. Hay preguntas de verificación, extracción de un dato y respuesta abierta. Cada contrato ocupa una fila de la matriz; cada pregunta, una columna. El abogado revisa las celdas que requieren atención antes de exportar los resultados a Excel.

La aplicación admite hasta cinco anexos para un caso individual y hasta 250 contratos por lote. Son capacidades, no volumen de adopción ni cantidad de casos procesados. La revisión por documento mantiene separada la evidencia de cada contrato, para que una cita no se atribuya al archivo equivocado.

Cómo interviene Gemini

Google Gemini es el proveedor de IA de la aplicación. El modelo por defecto documentado es gemini-2.5-flash, y el usuario puede elegir otro del catálogo disponible. Los prompts distinguen análisis jurídico, chat, profundización y extracción masiva; la extracción solicita respuestas estructuradas en JSON.

No se usa RAG ni una base vectorial. El documento completo se envía al modelo en cada llamada, un documento por llamada. Cuando un tema no aparece, el procesamiento puede realizar una segunda lectura con sinónimos. La fuente de conocimiento de SharePoint aporta documentos de referencia al chat y a la profundización; está prevista como activa en producción.

Extraer, comprobar y validar

Después de la respuesta del modelo, un verificador determinista compara la cita con el texto del PDF. Esta comprobación no es otra opinión de IA: contrasta el fragmento con el documento. El resultado conserva la respuesta, la página, el texto citado y el estado de verificación para facilitar la revisión.

Los resultados que requieren atención quedan señalados para el abogado. La IA lee, extrae y propone; la persona valida las celdas y conserva la decisión jurídica. La matriz y las citas son una ayuda para analizar los documentos, no una aprobación automática ni un dictamen que sustituya al profesional.

Arquitectura y comunicaciones

React 18, servido por nginx, ofrece la interfaz. FastAPI sobre Python 3.11 atiende la API REST/JSON y coordina el análisis. PostgreSQL 15 conserva casos, lotes, usuarios y hallazgos; los archivos no se guardan en esa base, sino en SharePoint mediante Microsoft Graph. Las llamadas a Gemini y Graph utilizan HTTPS.

La cola de lotes está en PostgreSQL y se ejecuta con asyncio dentro del mismo proceso del backend. Tiene concurrencia de cuatro documentos y hasta dos intentos por documento. Si se reinicia, los trabajos incompletos vuelven a encolarse. No requiere Redis ni Celery. El navegador consulta el avance periódicamente y solicita la descarga de resultados.

Estado y complementariedad

La aplicación nació como demo, se mejoró y está en despliegue para empezar a usarse. La versión con almacenamiento en SharePoint ya funciona. El Gantt conserva un avance del 83 % y un periodo aproximado del 16-ago al 17-oct-2026. Esos datos de planificación no deben confundirse con una adopción ya medida.

CaseLex y el Agente Jurídico de Copilot Studio son piezas complementarias de la solución jurídica. CaseLex hace análisis de casos y revisión de contratos; el agente responde consultas del procedimiento de contratación en Teams. La complementariedad es funcional: no supone una integración de API ni un chat incrustado entre ambos productos.

Componentes y responsabilidades

• Abogado: Carga, valida y decide
• React 18 · nginx: Interfaz de casos y lotes
• FastAPI: API REST y lógica jurídica
• PostgreSQL 15: Casos, hallazgos y cola
• SharePoint: Repositorio de documentos
• Google Gemini: Análisis y extracción
• Procesador de lotes: asyncio dentro del backend
• Verificador de citas: Comprobación sin IA

Comunicaciones

1. Abogado → React 18 · nginx: Carga contratos y un cuestionario reutilizable.
2. React 18 · nginx → FastAPI: Envía los documentos del lote por la API REST.
3. FastAPI → SharePoint: Guarda los archivos en SharePoint.
4. FastAPI → PostgreSQL 15: Registra referencias y documentos pendientes.
5. FastAPI → Procesador de lotes: Inicia el procesamiento del lote.
6. Procesador de lotes → SharePoint: Lee un documento completo por trabajo.
7. Procesador de lotes → Google Gemini: Solicita respuestas estructuradas, páginas y citas del contrato.
8. Google Gemini → Procesador de lotes: Devuelve los hallazgos de ese documento.
9. Procesador de lotes → Verificador de citas: Comprueba la cita contra el texto del PDF, sin IA.
10. Verificador de citas → PostgreSQL 15: Guarda hallazgos y marcas de revisión.
11. React 18 · nginx → FastAPI: Consulta el avance y presenta la matriz de resultados.
12. Abogado → React 18 · nginx: Valida las celdas y solicita la exportación a Excel.

Necesidad y experiencia de uso

Nexus AI Req acompaña el levantamiento de requisitos sin exigir que la persona redacte manualmente cada artefacto. Parte de actas, transcripciones, requerimientos y documentos técnicos, los reúne y pregunta lo que sigue siendo ambiguo. Lo usan personas de análisis y desarrollo, líderes y fábricas; no requiere un rol profesional específico para iniciar un requerimiento. El acceso ocurre en Agentes AI MP, plataforma compartida con otros módulos independientes.

El asistente de inicio admite hasta dieciséis archivos PDF, DOCX, PPTX, TXT o Markdown, de hasta veinte megabytes cada uno. La persona clasifica cada archivo, elige hasta veinte imágenes incrustadas y diligencia la ficha del proyecto. Después confirma el inicio, sigue el progreso en tiempo real y responde cuando la herramienta necesita una decisión.

Flujo durable y decisiones humanas

Temporal conserva el avance del proceso, permite reintentos y soporta pausas prolongadas para recibir respuestas. La ingesta precede a las dudas globales y a la unificación documental. Luego se propone un backlog, se revisan sus cabeceras y se redactan épicas. La persona puede editar, agregar o eliminar épicas e historias antes de escribirlas; también responde dudas específicas y aprueba cada épica.

Los puntos de aclaración admiten hasta tres rondas. Una pausa humana puede mantenerse hasta treinta días. Las épicas y los casos de uso se elaboran en paralelo, con concurrencia limitada. Si se alcanza el presupuesto, el workflow se pausa para decidir si continúa o se cancela, en lugar de interpretar el costo como autorización automática.

Qué hace la inteligencia artificial

PydanticAI ejecuta agentes con salidas estructuradas sobre OpenAI. GPT-5.4 planifica el backlog, escribe épicas y casos de uso y detecta dudas globales; GPT-5.4-mini apoya aclaraciones por épica, SQL, modelo de datos y visión; GPT-5.4-nano genera el glosario. La ficha describe ocho agentes y dos componentes Python sin IA: unificación de documentos y ensamblaje final.

La implementación vigente utiliza generación directa, no un ciclo de autocrítica. Temporal organiza el proceso exterior y cada agente produce su artefacto en una pasada. Los prompts combinan roles con instrucciones reutilizables para descomposición, estimación y criterios de aceptación. La lectura visual aporta contexto, mientras que las decisiones de negocio siguen dependiendo de las confirmaciones de la persona.

Arquitectura y comunicación

El navegador accede por HTTPS al proxy corporativo y al frontend React servido por nginx. La API FastAPI recibe los documentos, gestiona consultas y descarga, y utiliza WebSocket para publicar cambios de progreso. Mediante gRPC inicia Temporal, consulta su estado y comunica las respuestas humanas. El worker recibe actividades del servicio Temporal y realiza el trabajo del pipeline.

PostgreSQL de la plataforma guarda usuarios, permisos, workflows, eventos, archivos y costos. La persistencia de Temporal mantiene separadamente la durabilidad del proceso. El worker llama a OpenAI por HTTPS y al renderizador DBML por HTTP. Los archivos pueden guardarse localmente o en SharePoint mediante Microsoft Graph. Phoenix, OpenTelemetry, Prometheus y alertas complementan el seguimiento técnico.

Entregables y controles

La descarga reúne historias de usuario con criterios Gherkin y casos de uso estilo Cockburn en plantillas Word corporativas. También incluye un script SQL Oracle validado, el modelo entidad-relación en DBML, SVG y PNG, y un archivo de descripción con los metadatos. El paquete ZIP conserva estos resultados como artefactos utilizables por quienes continúan el proyecto.

Antes de enviar texto al modelo se enmascaran datos personales y se revisan intentos de inyección de instrucciones. El validador SQL comprueba el dialecto Oracle y bloquea operaciones no permitidas. Cada llamada registra consumo y costo, verifica presupuesto y se protege frente a fallos del proveedor. El acceso usa autenticación propia, revocación y permisos por módulo.

Resultado, alcance y estado

El proyecto figura completado y opera dentro de la plataforma desplegada. Las cifras oficiales de la presentación sitúan un requerimiento entre diez y veinte minutos frente a una semana de trabajo anterior; el video también informa quince personas usuarias y catorce requerimientos completos en el mes referido. Son cifras documentadas, no contadores actuales ni garantías universales de duración.

La ficha se diligencia manualmente. No existe OCR general para imágenes sueltas o PDF escaneados: la visión describe las imágenes incrustadas que se seleccionan. Estas descripciones apoyan el contexto y las imágenes no se insertan en los Word. Los diagramas entregados son del modelo entidad-relación; no se generan diagramas de flujo de casos de uso.

Componentes y responsabilidades

• Persona: Documentos y decisiones
• Portal y proxy: React · nginx · entrada HTTPS
• API FastAPI: Carga, progreso y respuestas
• Temporal: Flujo durable y pausas humanas
• Worker Nexus: Actividades y agentes tipados
• OpenAI: Generación y visión
• PostgreSQL plataforma: Estado, eventos y costos
• PostgreSQL Temporal: Persistencia del workflow
• Renderizador DBML: Modelo en SVG y PNG
• Archivos y SharePoint: Insumos y entregables
• Trazas y métricas: Phoenix · Prometheus · alertas

Comunicaciones

1. Persona → Portal y proxy: Carga documentos, selecciona imágenes y diligencia la ficha
2. Portal y proxy → API FastAPI: Envía insumos mediante REST y abre progreso WebSocket
3. API FastAPI → PostgreSQL plataforma: Registra workflow, archivos y eventos
4. API FastAPI → Temporal: Inicia el workflow durable
5. Temporal → Worker Nexus: Coordina las actividades del pipeline
6. Worker Nexus → OpenAI: Solicita visión, dudas y propuestas de backlog
7. Persona → API FastAPI: Responde dudas y revisa backlog y épicas
8. API FastAPI → Temporal: Entrega la confirmación y reanuda el flujo
9. Worker Nexus → OpenAI: Genera historias, casos de uso, SQL y DBML
10. Worker Nexus → Renderizador DBML: Convierte el DBML en SVG y PNG
11. Worker Nexus → Archivos y SharePoint: Ensambla y guarda el ZIP de entregables
12. API FastAPI → Portal y proxy: Entrega el paquete para descarga

Qué servicio se registra

Un servicio genérico expone un procedimiento PL/SQL de Oracle mediante el bus corporativo y un nombre clave. Las aplicaciones pueden invocarlo con un contrato estándar en lugar de construir una integración diferente para cada necesidad. El módulo ayuda al desarrollador a registrar esa definición y centraliza el servicio, sus parámetros, errores, contrato y trazabilidad en la misma aplicación.

Antes, la solicitud entraba en una fila de Arquitectura y el contrato se digitaba en una macro Excel. Parte de la información quedaba en archivos separados y luego se subía a SharePoint. El nuevo flujo permite preparar el registro directamente en Agentes AI MP, sin convertir la ayuda de IA en una autorización para modificar el catálogo oficial.

Preparar, revisar y registrar

La persona indica el procedimiento y su origen de datos, pega o carga el código y solicita el análisis. El sistema verifica duplicados tanto localmente como en el catálogo del bus. La propuesta organiza propósito, tipo de operación, parámetros de entrada, columnas de salida y errores. El nombre clave se valida con reglas de formato y contra los nombres existentes.

La revisión humana puede corregir cualquiera de estos datos. Hay dos confirmaciones distintas: primero se aprueba el contenido del servicio y después se acepta el registro en la base de datos. La interfaz distingue borradores, propuestas, registros en QA, resultados de prueba y contratos. Las transiciones válidas quedan controladas y los cambios se registran como eventos.

IA y análisis determinista

PydanticAI utiliza OpenAI GPT-5.4-mini para interpretar la firma del procedimiento y proponer descripciones, entradas, errores y candidatos de nombre. Las salidas tienen estructura tipada. Los comentarios se revisan para detectar instrucciones ajenas al propósito del análisis y los datos personales se enmascaran antes de enviar el contenido al modelo. La propuesta no se configura sin aprobación.

Las columnas de salida no dependen de una suposición del modelo: se resuelven a partir del SELECT del cursor y de los metadatos de Oracle. La IA redacta las descripciones de esas columnas, pero no sustituye su determinación. El nombre puede proponerse mediante varios candidatos validados; si ninguno resulta adecuado, la persona puede escribirlo y someterlo a las mismas comprobaciones.

Arquitectura síncrona y límites de escritura

El navegador llega por HTTPS al proxy corporativo y al frontend React servido por nginx. La API FastAPI ejecuta el flujo de forma síncrona; este módulo no usa Temporal. PostgreSQL conserva borradores, fuentes, propuestas, eventos, auditoría y costos. La API llama a OpenAI por HTTPS y puede leer metadatos y el catálogo de Oracle mediante Oracle Net.

La conexión directa con Oracle es de solo lectura. Las escrituras se solicitan por HTTPS REST al bus MCS, que ejecuta procedimientos corporativos sobre las tablas de propuesta de QA. Primero se crea una cabecera inactiva, después se agregan entradas, se verifican y se completan salidas y errores. La activación ocurre únicamente al concluir correctamente, no a mitad del registro.

Contrato, trazabilidad y acceso

El contrato Excel se genera a demanda desde una plantilla corporativa de siete hojas: resumen, autorización, estructura de entrada, estructura de salida, errores, ejemplos y evidencia. Su información proviene del registro revisado. La plantilla se verifica antes de usarla y el archivo se consulta y descarga desde la aplicación, sin un traslado manual adicional a SharePoint.

Las operaciones tienen permisos diferenciados para consultar, crear, usar IA, configurar QA, probar, generar contratos y administrar. El sistema conserva eventos, versiones del contenido y evidencia sanitizada. Un control de operación limita ejecuciones duplicadas; si una operación falla, su estado y sus eventos permiten revisar lo ocurrido. Las trazas de IA, métricas y registros de costo complementan esa trazabilidad.

Oracle, operado por el bus, y PostgreSQL no comparten una transacción distribuida. La consistencia depende de la creación inactiva, las verificaciones posteriores a la escritura, los controles contra ejecuciones repetidas y los eventos de fallo. Un rechazo de cabecera detiene el registro sin continuar las operaciones siguientes.

Qué está disponible y qué falta

El proyecto registra cuarenta por ciento de avance en el Gantt y está en uso en el ambiente de pruebas, todavía sin liberación. Están construidos el registro asistido, la doble confirmación, las escrituras de propuesta en QA, el contrato y la trazabilidad. La cifra oficial de diez minutos describe el registro de un servicio con contrato; no significa que el paso a producción esté habilitado.

La prueba automática en QA depende de que el componente ejecutor pueda resolver los servicios de las tablas de propuesta; ese cambio sigue pendiente. Mientras tanto, el contrato se habilita con el registro vigente. La búsqueda en lenguaje natural es una próxima mejora sin fecha: actualmente hay filtros por texto. El video muestra una intención futura, no una capacidad ya liberada del módulo.

Componentes y responsabilidades

• Desarrollador: Fuente PL/SQL y dos confirmaciones
• Portal y proxy: React · nginx · acceso HTTPS
• API FastAPI: Flujo síncrono del asistente
• OpenAI: Análisis y descripciones
• PostgreSQL: Borradores, eventos y auditoría
• Oracle QA: Metadatos y catálogo de propuesta
• Bus MCS: Registro y ejecución de servicios
• Contrato Excel: Plantilla corporativa de 7 hojas
• Trazas y métricas: Phoenix · Prometheus · costos

Comunicaciones

1. Desarrollador → Portal y proxy: Indica procedimiento, origen y código PL/SQL
2. Portal y proxy → API FastAPI: Crea el borrador y solicita análisis
3. API FastAPI → Bus MCS: Comprueba duplicados y nombres existentes
4. API FastAPI → Oracle QA: Lee metadatos para resolver salidas deterministas
5. API FastAPI → OpenAI: Propone identidad, entradas, errores y descripciones
6. API FastAPI → PostgreSQL: Guarda la propuesta y sus eventos
7. Desarrollador → API FastAPI: Revisa, corrige y confirma el contenido
8. Desarrollador → API FastAPI: Confirma por separado el registro en QA
9. API FastAPI → Bus MCS: Solicita cabecera inactiva, parámetros, verificación y activación
10. Bus MCS → Oracle QA: Registra únicamente en el catálogo de propuesta
11. API FastAPI → Contrato Excel: Genera el contrato corporativo a demanda
12. API FastAPI → Portal y proxy: Entrega contrato y estado; prueba automática pendiente

El harness no es la aplicación

El Asistente de Desarrollo Coomeva es un harness: una configuración compartida para trabajar con IA sobre el arquetipo corporativo. No es un asistente para afiliados ni una funcionalidad de IA dentro de cada producto. El arquetipo ya existía como base Angular y Java; este proyecto añade método, instrucciones, roles y evidencia para el desarrollo asistido.

Un equipo recibe tres repositorios independientes: coordinador, frontend y backend. El prompt de inicio permite crear una aplicación nueva o adoptar la base en una existente y vincular sus versiones. El objetivo es compartir arquitectura, convenciones y documentación entre desarrolladores y fábricas, en vez de depender de instrucciones improvisadas.

Una fuente de reglas para tres herramientas

El catálogo de agentes y skills vive en .agents y las reglas generales en AGENTS.md. Generadores PowerShell proyectan esa fuente a los formatos de Claude Code, Codex y OpenCode; una verificación comprueba que las proyecciones estén sincronizadas. Así se evita mantener tres manuales divergentes y se conserva un mismo flujo para investigar, implementar, revisar y documentar, aunque cambie la herramienta utilizada por el equipo.

La configuración documenta cinco roles: investigación del código, especialidad frontend, especialidad backend, revisión de superficies críticas y gobierno de documentación. Los skills empaquetan tareas como inception, preparación de requerimientos, análisis de impacto, ciclos de cambio y cierre. La integración de Spec Kit aporta especificación, aclaraciones, checklist, plan, tareas y análisis. Los agentes no reciben una autorización general para cambiar cualquier parte del producto; trabajan sobre el alcance del requerimiento.

Orientación y modelos según la función

La brújula lee el estado real del proyecto y propone una sola siguiente acción; no la ejecuta. Los hooks de Claude Code y Codex incorporan orientación al inicio, checkpoints antes de compactar y recordatorios de cierre. OpenCode utiliza un plugin para el control de acciones y solicita la brújula de manera manual. PowerShell 7 es el runtime de los scripts y generadores, mientras que el plugin de OpenCode utiliza JavaScript.

Una política asigna modelos y esfuerzo por rol. La configuración documentada usa gpt-6.1-sol para implementación y revisión en Codex, y gpt-6-luna para investigación y documentación. Claude Code utiliza Sonnet para investigar o implementar y Opus para revisar. OpenCode hereda el modelo de la sesión. Codex figura como herramienta principal del equipo.

De la idea a un cambio aprobado

El flujo empieza por entender la idea. Antes de escribir producto, la inception prepara PRD, flujo de aplicación, UI/UX, documento técnico, esquemas de backend y plan de implementación. Cada cambio posterior se gestiona como requerimiento con su carpeta de intake, análisis, plan, estado y prompts secuenciales. La especificación y la división en tareas conservan las decisiones del negocio y reducen las suposiciones del agente.

Una persona aprueba el plan antes de la implementación. Los especialistas trabajan por bloques con una política de pruebas primero: observar la prueba fallar, implementar lo necesario y mantenerla pasando al refactorizar. Para cambios pequeños existe un ciclo liviano. El proceso no convierte la documentación en permiso automático para modificar o publicar; la decisión humana permanece en los puntos clave y las ampliaciones del trabajo deben corresponder al requerimiento.

Evidencia, documentación y publicación humana

La finalización requiere evidencia. Las verificaciones reúnen pruebas, estándares y comprobaciones visuales y distinguen fallos previos de problemas introducidos por el cambio. En superficies críticas, el revisor realiza dos pasadas independientes. Los resultados, decisiones, runbooks y handoffs quedan documentados para que una sesión posterior pueda retomar el trabajo sin comenzar de cero. Las lecciones pueden originar propuestas de mejora del propio harness, cuya aceptación sigue siendo humana.

El agente prepara la rama, los cambios y el material del PR; la persona ejecuta commit, push y publicación. Los PR de los repositorios se validan con Azure Pipelines y, tras merge a las ramas de ambiente, se construyen y publican imágenes Docker en Azure Container Registry. Ese pipeline no despliega el servicio. La promoción dev, QA, staging y producción conserva sus decisiones ordinarias de aprobación; generar una imagen no equivale a ponerla en ejecución.

La base técnica conserva un estándar común

El frontend de referencia utiliza Angular 21, componentes standalone, Angular Material, NgRx Signals, RxJS, TypeScript y Tailwind sobre tokens corporativos. Se organiza en core, shared, features y layouts y comprueba sus fronteras de importación. Un mismo build recibe configuración por ambiente en ejecución y se sirve con nginx. Las pruebas incluyen Karma, Jasmine, fast-check y comprobaciones visuales con Playwright.

El backend usa Java 21, Spring Boot 4.1 y Spring Cloud, con arquitectura hexagonal comprobada mediante ArchUnit. La base incluye gateway, Eureka, autenticación, adaptadores de servicios genéricos y proxy, servicios de ejemplo, plantilla y librería común. La persistencia de referencia es Oracle con JPA. Las pruebas incluyen JUnit, Mockito, AssertJ, jqwik y JaCoCo. El arquetipo contiene ejemplos técnicos, no el negocio del sistema de origen.

Adopción y evolución sin porcentajes inventados

El Gantt sitúa el trabajo aproximadamente entre agosto y septiembre de 2026 y el uso real comenzó a inicios de septiembre. La versión documentada al 7 de octubre es v4.9.0. Se registran ocho aplicaciones usuarias: SOFIB, OVAM, ADM, GSA, SOLCOMPRAS, CORA, OVPM y MSCM. La ficha confirma la última como incorporación adicional a las siete mostradas en el video; no se deduce que compartan los mismos detalles de negocio.

Cada versión publica un manifiesto con cambios por repositorio y las aplicaciones conservan un recibo de la versión adoptada. Esto permite contrastar qué actualizaciones faltan y mantener evolución continua. El beneficio comunicado es cualitativo: menos repetición, un estándar compartido y documentación recuperable. No existe una medición de ahorro que permita afirmar un porcentaje o una reducción concreta del tiempo de entrega. La evidencia de adopción y la expectativa de eficiencia se presentan por separado.

Componentes y responsabilidades

• Desarrollador: Define, aprueba y publica
• Herramienta de IA: Codex · Claude Code · OpenCode
• Fuente de reglas: AGENTS.md + catálogo .agents
• Adaptadores: Proyecciones por herramienta
• Hooks y plugin: PowerShell 7 + plugin OpenCode
• Brújula: Estado real → siguiente acción
• Agentes y skills: Roles especializados + Spec Kit
• Frontend Angular: Arquetipo · repositorio propio
• Backend Java: Arquetipo · microservicios Spring
• Documentación viva: REQ, ADR, handoffs y lecciones
• Verificación: Pruebas, revisión y evidencia
• Entrega validada: Bitbucket → Azure Pipelines → ACR

Comunicaciones

1. Desarrollador → Herramienta de IA: Abre la sesión y presenta el requerimiento.
2. Herramienta de IA → Hooks y plugin: Activa la orientación de inicio y los controles del flujo.
3. Hooks y plugin → Brújula: Consulta el estado real del proyecto.
4. Brújula → Herramienta de IA: Indica una siguiente acción sin ejecutarla.
5. Herramienta de IA → Agentes y skills: Investiga contratos y prepara el requerimiento.
6. Agentes y skills → Documentación viva: Documenta análisis, especificación, plan y tareas.
7. Desarrollador → Agentes y skills: Aprueba el plan antes de implementar.
8. Agentes y skills → Frontend Angular: Implementa un cambio frontend ilustrativo con TDD; backend sigue el mismo patrón.
9. Agentes y skills → Verificación: Ejecuta pruebas, verificación y revisión crítica aplicable.
10. Verificación → Documentación viva: Registra evidencia y handoff.
11. Herramienta de IA → Desarrollador: Prepara rama, cambios y descripción de publicación; no los publica.
12. Desarrollador → Entrega validada: Realiza commit, push, PR y merge; CI valida y genera la imagen sin desplegar.

La IA como forma de construir

El énfasis de Impulso Vital es su construcción asistida por inteligencia artificial: pasó de cero a producción en unas tres semanas, frente a dos o tres meses estimados para un desarrollo tradicional. La IA colaboró en las especificaciones, el código y las pruebas sobre los arquetipos corporativos. No se contrató una fábrica externa para desarrollar esta aplicación.

El trabajo comenzó por documentación fiel al negocio: requisitos, flujo de la aplicación, diseño de interfaz, decisiones técnicas, esquemas y plan. Los módulos se desarrollaron con prompts autocontenidos, especificaciones y verificación. Claude Code y Codex formaron parte de las herramientas utilizadas. Las decisiones relevantes y la aprobación de cambios, entregas visuales y pruebas de aceptación permanecieron bajo revisión humana.

El material de desarrollo registra veintinueve especificaciones completadas, diez entregas de aceptación, agentes especializados e instrucciones reutilizables. Los revisores automáticos propios comprobaban el apego a los arquetipos corporativos. Son características documentadas de aquella construcción, no una atribución de las herramientas actuales del portafolio a la aplicación.

Qué reúne para el seguimiento

La plataforma concentra el recorrido de participantes del piloto de salud en Cali y Medellín. Reemplaza información dispersa entre mensajes, hojas de cálculo, correos y sistemas de aliados por un registro común con cada gestión documentada. Las cifras oficiales informan trescientos dos participantes activos y cuarenta y cuatro personas usuarias distribuidas en siete roles de trabajo.

El recorrido incluye encuesta, agendamiento, valoraciones interdisciplinarias, veredicto de aptitud, activación del protocolo, inducción, seguimientos, valoración final y cierre. El protocolo activado inicia un contador de noventa días. El sistema exige condiciones para avanzar y evita saltos de etapa. También contempla abandono y no aptitud, sin convertir una recomendación informática en una decisión clínica automática.

Cada rol conserva su responsabilidad

Administración gestiona usuarios, reasignaciones, cargas, auditoría y exportes. El agente oficial acompaña sus participantes asignados, registra bitácoras, cambios de etapa, documentos y seguimientos. El agente de backoffice ve el conjunto y opera las cargas. Nutrición, Psicología y Medicina deportiva completan sus valoraciones; Medicina deportiva también registra la valoración final. Enfermería integra las valoraciones y decide la aptitud y activación.

Los menús y capacidades limitan acciones por rol, y el backend vuelve a comprobar los permisos. Los agentes no ven la valoración psicológica. El detalle de la encuesta se reserva a perfiles autorizados. Las correcciones requieren motivo y los cambios quedan auditados campo a campo. La decisión de Enfermería determina el avance posterior del recorrido.

Cargas, documentos y entregables

Las cargas incluyen participantes, encuesta de salud exportada desde Microsoft Forms, datos SINET y mediciones de SmartFit, Fisify y Motivia. La persona valida primero el archivo, revisa errores por fila y confirma después. Los lotes se deduplican mediante una huella del contenido y pueden anularse indicando el motivo, conservando el registro de la operación.

La información puede exportarse en una sábana Excel para seguimiento y BI. Los documentos clínicos se generan como PDF individual o en descarga masiva ZIP. Los archivos de participantes se organizan en SharePoint por identificador interno. La aplicación ofrece plantillas de WhatsApp por etapa para copiar manualmente; no existe envío automático ni una integración de mensajería que deba suponerse.

Arquitectura y comunicación operativa

La entrada web pasa por el proxy corporativo con HTTPS y por nginx, que sirve la SPA Angular. El API Gateway valida la sesión y enruta mediante HTTP a autenticación o al servicio de negocio. Eureka permite descubrir esos servicios. Autenticación mantiene usuarios, roles y sesiones, mientras que el servicio Impulso gestiona participantes, valoraciones, etapas, cargas, documentos y exportaciones.

Los servicios usan JDBC para persistir en dos bases PostgreSQL separadas: autenticación y negocio. El servicio de negocio se comunica con autenticación para sesiones y directorio de agentes. Los documentos pendientes se sincronizan con SharePoint por HTTPS mediante Microsoft Graph y un outbox asíncrono. Angular y Spring Boot constituyen la aplicación; Docker, Azure Container Registry y Portainer soportan sus entregas.

Estado, protección y alcance de la IA

Impulso Vital está en producción y mantiene uso activo. Sus mejoras posteriores incluyeron documentos clínicos, facilidades para cargas, seguimiento por aliado y descarga masiva. La aplicación dispone de pruebas de backend, frontend y recorridos de usuario, además de verificación de la arquitectura. Las cantidades oficiales describen el proyecto y el video de referencia, no una lectura instantánea del sistema.

La IA no participa en tiempo de ejecución: no hay un modelo tomando decisiones sobre personas durante el seguimiento. Su intervención pertenece a la construcción de especificaciones, código y pruebas. La privacidad se protege con acceso por rol, sesiones verificadas, restricciones a información sensible y auditoría. Los textos clínicos se redactan en la auditoría y las personas responsables conservan la decisión clínica y operativa.

Componentes y responsabilidades

• Usuarios internos: Seguimiento según rol
• Proxy corporativo: Entrada HTTPS
• Frontend Angular: SPA servida por nginx
• API Gateway: Sesión, permisos y enrutamiento
• Autenticación: Usuarios, roles y sesiones
• Servicio Impulso: Participantes y seguimiento
• Eureka: Descubrimiento de servicios
• PostgreSQL auth: Identidad y sesiones
• PostgreSQL negocio: Recorrido y auditoría
• SharePoint: Documentos vía outbox
• Excel y PDF: Sábana, clínicos y ZIP

Comunicaciones

1. Usuarios internos → Frontend Angular: Carga Excel y solicita una vista previa de validación
2. Frontend Angular → API Gateway: Envía la solicitud autenticada
3. API Gateway → Autenticación: Comprueba que la sesión siga activa
4. API Gateway → Servicio Impulso: Entrega la operación al servicio de negocio
5. Servicio Impulso → Frontend Angular: Devuelve errores por fila antes de guardar
6. Usuarios internos → Servicio Impulso: Confirma la carga revisada
7. Servicio Impulso → PostgreSQL negocio: Registra lote, participantes, asignación y auditoría
8. Usuarios internos → Servicio Impulso: Completa encuesta y valoraciones según su rol
9. Usuarios internos → Servicio Impulso: Enfermería decide aptitud y activa el protocolo
10. Servicio Impulso → PostgreSQL negocio: Conserva etapas, seguimientos y cambios auditados
11. Servicio Impulso → SharePoint: Sincroniza documentos pendientes mediante outbox
12. Servicio Impulso → Excel y PDF: Genera sábana Excel, PDF clínico o ZIP masivo

Un lugar común para continuar el trabajo

Gestión MP reúne las iniciativas y los proyectos de IA del equipo de Medicina Prepagada. Antes, el seguimiento estaba disperso y era difícil vincular un proyecto con sus tareas, decisiones, reuniones y documentos. El portafolio permite consultar etapa, avance, área, prioridad y responsables sin reconstruir la historia en varias herramientas.

El detalle de cada proyecto contiene tareas en Kanban, notas, reuniones con participantes y acuerdos vinculados a tareas, y adjuntos en SharePoint. Las tareas globales y el cronograma Gantt ofrecen otras formas de consultar el trabajo. La aplicación es una herramienta de gestión; no debe presentarse como un agente que decide el portafolio.

Una integración real: radicar iniciativas

Agentes AI MP dispone del módulo Iniciativas IA. Desde allí se radica una solicitud en la API de Gestión MP, que la conserva como RADICADA en la bandeja de Solicitudes. La identidad del sistema de origen y el identificador externo permiten reconocer reenvíos y evitar que una misma iniciativa se duplique.

El equipo revisa la solicitud y puede aprobarla, aprobar con condiciones, devolverla, rechazarla o escalarla. Según la decisión, se exige una nota de revisión. Una solicitud aprobada puede convertirse en un proyecto, vincularse a uno existente o quedar aprobada sin crear proyecto. Nexus y Servicios Genéricos comparten la plataforma de origen, pero no son el flujo documentado de radicación.

Etapas y avance registrados por el equipo

Un proyecto puede recorrer idea aprobada, diseño, construcción, pruebas y entregado; también puede pausarse y retomarse. Las tareas siguen pendiente, en progreso y finalizada, y se mueven en el Kanban. Las reuniones, sus acuerdos y las notas pueden relacionarse con tareas para que el siguiente paso conserve contexto.

El avance porcentual del proyecto lo registra una persona, y cada cambio requiere un comentario. Al llegar a entregado pasa al 100 %. El historial deja constancia de la evolución. El tablero y el Gantt muestran esa información registrada; no infieren por IA qué proyecto está terminado ni sustituyen la decisión del equipo.

Arquitectura modular y comunicaciones

La aplicación combina una SPA React 19 servida por nginx y un backend FastAPI sobre Python 3.13. Son dos contenedores. El backend es un monolito modular con arquitectura hexagonal pragmática; solicitudes, proyectos, tareas y documentos forman parte de esa aplicación, no de una red de microservicios separados.

La interfaz utiliza la API REST a través de nginx. FastAPI conserva los datos en Oracle mediante Oracle Net; las radicaciones desde Iniciativas IA entran por HTTP a la API. Los documentos se organizan en SharePoint mediante Microsoft Graph y HTTPS. La base guarda los registros del trabajo y los trabajos pendientes de archivos.

Documentos, acuerdos y continuidad

Al crear un proyecto se programa la creación de su carpeta en SharePoint. Un outbox conserva trabajos pendientes en Oracle y un proceso del backend los atiende cada quince segundos. Así, el registro del proyecto y el trabajo documental quedan coordinados sin obligar a que todas las llamadas de archivos terminen dentro de la interacción del usuario.

Los adjuntos se conservan asociados al proyecto junto con notas y reuniones. El objetivo es que el equipo encuentre la evidencia y los acuerdos que necesita para continuar. El Gantt de proyectos y tareas es propio de la aplicación; el Kanban organiza la ejecución diaria. Estas vistas se complementan, sin convertir cada visualización en un sistema independiente.

Construida con IA, en evolución continua

El desarrollo comenzó con documentos de producto, flujo, diseño, requisitos técnicos, esquemas y plan. Después se utilizó Spec Kit y un enfoque de pruebas primero, con agentes de Claude Code, Codex y OpenCode. Es una experiencia de desarrollo asistido: la aplicación resultante se dedica a organizar el trabajo y conserva la revisión humana de las iniciativas.

Gestión MP está en producción y continúa ajustándose a lo que necesita el equipo. El Gantt registra un periodo aproximado del 17-jun al 18-jul-2026; la evolución funcional siguió después. Al 29-jul había 21 proyectos registrados y seis entregados. Estas cifras evidencian uso en esa fecha, no representan una medición actualizada a octubre ni deben proyectarse como ahorro de tiempo.

Componentes y responsabilidades

• Equipo MP: Revisa y gestiona proyectos
• React 19 · nginx: Portafolio y trabajo diario
• FastAPI: Monolito modular · API
• Oracle: Proyectos, solicitudes y outbox
• Iniciativas IA: Origen en Agentes AI MP
• Solicitudes: Bandeja de revisión
• Proyectos: Etapas, tareas y acuerdos
• Outbox de archivos: Trabajos asíncronos
• SharePoint: Carpeta por proyecto
• Gantt y Kanban: Planificación y seguimiento

Comunicaciones

1. Iniciativas IA → FastAPI: Radica una iniciativa desde Agentes AI MP.
2. FastAPI → Oracle: Registra la solicitud y evita duplicados por su identidad de origen.
3. FastAPI → Solicitudes: Deja la iniciativa radicada en la bandeja de revisión.
4. Equipo MP → React 19 · nginx: Consulta la solicitud y registra su decisión.
5. React 19 · nginx → FastAPI: Envía la revisión y, si corresponde, la conversión en proyecto.
6. FastAPI → Oracle: Guarda la decisión y crea el proyecto aprobado.
7. FastAPI → Outbox de archivos: Programa la creación de la carpeta documental.
8. Outbox de archivos → SharePoint: Crea la carpeta por Microsoft Graph.
9. Outbox de archivos → Oracle: Registra que el trabajo documental terminó.
10. Equipo MP → React 19 · nginx: Continúa con tareas, notas, reuniones, adjuntos y cronograma.