¿Cómo diseñar una arquitectura empresarial que combine Azure AI Foundry, Semantic Kernel y un sistema Multi-Agente basado en RAG para una plataforma de inteligencia contable desarrollada en C#?

Darick Yael Gonzalez Mellado 0 Puntos de reputación
2026-07-30T16:42:35.96+00:00

Busco una arquitectura escalable que considere:

  • Semantic Kernel como orquestador.
  • Azure AI Foundry para modelos, evaluaciones y observabilidad.
  • Azure AI Search como motor RAG.
  • Almacenamiento vectorial para documentos contables.
  • Agentes especializados por dominio contable.
  • Memoria de conversación y contexto.
  • Integración con ERP (SAP, Dynamics, Odoo, etc.).
  • Seguridad basada en Microsoft Entra ID y RBAC.
  • Despliegue en Azure con buenas prácticas de producción.
Microsoft Foundry
Microsoft Foundry

Una plataforma unificada de Azure para crear y administrar modelos, agentes y aplicaciones de IA con seguridad, supervisión y gobernanza empresariales integradas

0 comentarios

2 respuestas

Ordenar por: Muy útil
Muy útil Más reciente Más antiguo
  1. Manish Deshpande 8,220 Puntos de reputación Personal externo de Microsoft Moderador
    2026-07-30T18:43:32.4133333+00:00

    Hello @Darick Yael Gonzalez Mellado

    Gracias por detallar los requisitos de manera tan clara, este es un stack bien definido y la mayoría de tus elecciones son las que yo haría. Abajo tienes una arquitectura de referencia mapeada a tus puntos, además de tres decisiones que vale la pena definir temprano porque son costosas de retroalimentar.

    Primero: una guía sobre el orquestador

    Las funciones de Orquestación de Agentes de Semantic Kernel están documentadas actualmente como "en etapa experimental… en desarrollo activo y pueden cambiar significativamente antes de avanzar a la versión preliminar o candidata para lanzamiento." Para una plataforma contable en producción, eso es algo que vale la pena saber antes de construir sobre ella.

    El Microsoft Agent Framework se documenta como "el sucesor directo" tanto de Semantic Kernel como de AutoGen, "creado por los mismos equipos" — combina las abstracciones de agente de AutoGen con las funciones empresariales de SK (estado de sesión, seguridad de tipos, middleware, telemetría) y agrega flujos de trabajo basados en grafos con puntos de control y soporte humano en el bucle.

    Para un proyecto nuevo en C#, yo empezaría por ahí en lugar de migrar después. Dos advertencias honestas: (1) Agent Framework es en sí un SDK joven — por favor verifica el estado actual de GA/preview de los componentes específicos de los que dependes según la documentación en el momento en que te comprometas, en lugar de cualquier fecha citada en un hilo de foro; (2) Semantic Kernel sigue estando soportado, así que si ya tienes inversión en SK, esto es un mensaje de "planea la migración", no de "detente y reescribe". Tus plugins, conectores y conceptos de memoria de SK se trasladan de cualquier manera.

    Los aspectos destacados de la migración que afectan tu diseño: los espacios de nombres se mudan a Microsoft.Agents.AI (con los tipos principales de Microsoft.Extensions.AI), y las clases de agentes separadas (ChatCompletionAgent, AzureAIAgent, OpenAIAssistantAgent) se consolidan en un solo ChatClientAgent.

    **1. Capa de orquestación (C# / ASP.NET)
    **Imagen del usuario

    Para el enrutamiento simple, los Agentes Conectados en Foundry Agent Service permiten que un enrutador registre especialistas como herramientas llamables sin necesidad de crear un orquestador personalizado. Usa flujos de trabajo multiagente completos cuando una tarea realmente implique a agentes en secuencia. Todos admiten aprobaciones con intervención humana, algo esencial para cualquier cosa relacionada con registros financieros.

    2. Agentes contables especializados

    Modela cada dominio como su propio agente con un aviso de sistema específico y una superficie de herramientas mínima: Cuentas por pagar/cobrar, Libro mayor y diarios, Cumplimiento de impuestos/IVA, Conciliación, Reportes financieros y variaciones, Registro de auditoría. Un alcance de herramientas limitado es el mayor impulsor de la fiabilidad en sistemas multiagente en producción, y te permite evaluar y versionar cada agente de forma independiente. Cuando un dominio necesita acceso a datos aislados (impuestos vs. libro mayor), asígnale su propio proyecto en Foundry en lugar de compartir conexiones.

    Herramientas como sus propias clases con atributos descriptivos para que el modelo las seleccione correctamente:

    [KernelFunction, Description("Retrieve the trial balance for a given entity and period")]
public async Task<TrialBalance> GetTrialBalanceAsync(string entityId, string period) { ... }

    3. Capa RAG: por favor, diseña los derechos desde el día uno

    Esta es la parte que más te animaría a no posponer, y hay un matiz importante de estado que vale la pena conocer:

    Dos enfoques, diferente nivel de madurez:

    • Filtros de seguridad / recorte (GA — punto de partida recomendado). Almacena la identidad o los IDs de grupo de Entra en un campo de cadena que se pueda filtrar en cada documento, y pasa la identidad del que consulta como filtro en la búsqueda. Hoy en día está completamente soportado y es suficiente para la segregación de entidad/cliente/centro de costos.
    • Metadatos de permisos de Entra ID / ingestión que conserva ACLs (preview). Más completo — captura ACLs POSIX de ADLS Gen2, ACLs de SharePoint o etiquetas de sensibilidad de Purview al momento de indexar y recorta en el momento de la consulta. Requiere APIs REST en preview (actualmente 2026-05-01-preview), y ten en cuenta esta advertencia documentada: las ACLs se capturan solo durante la indexación inicial, así que debes reindexar los documentos afectados cuando cambien los permisos del origen o las decisiones de acceso queden desactualizadas.

    Para una plataforma contable multi-cliente, yo construiría sobre filtros de seguridad ahora y evaluaría el camino ACL a medida que madura; la advertencia del reindexado de vista previa es una obligación operativa real, no una nota al pie.

    Diseño del índice: usa vectorización integrada y una canalización de habilidades para fragmentar en lugar de crear embeddings manualmente, y utiliza búsqueda híbrida (vector + palabra clave) con ranking semántico, no solo vectorial. Esto importa mucho para contabilidad: los números de factura, códigos GL y nombres de entidad son tokens de coincidencia exacta que la búsqueda puramente vectorial maneja mal. Lleva entityId, período, tipo de documento, sourceUri como metadatos filtrables para que los agentes puedan acotar la recuperación de manera determinista. La recuperación agentiva (el LLM descompone una pregunta en subconsultas paralelas) vale la pena evaluarla después del MVP; híbrido + rankeador semántico es el punto de partida más seguro.

    4. Almacenamiento de vectores

    Azure AI Search también funciona como tu almacenamiento de vectores, así que no necesitas una base de datos de vectores aparte. Tanto SK como el Agent Framework acceden a él a través de la abstracción Microsoft.Extensions.VectorData, por lo que no estás atado a un solo almacenamiento si más adelante necesitas cambiarlo.

    1. Memoria y contexto de la conversación

    Dividido en dos preocupaciones:

    Memoria del hilo/sesión — la transcripción del chat. Si usas Foundry Agent Service, el estado del hilo se maneja del lado del servidor, así que no necesitas crear tu propio historial.

    Estado empresarial/a largo plazo — entidad seleccionada, período abierto, preferencias del usuario, contexto de auditoría y recuerdo entre sesiones ("este proveedor fue marcado como de alto riesgo el mes pasado"). Guárdalo en Azure Cosmos DB; para el recuerdo semántico, un proveedor de memoria de historial de chat respaldado por un almacén vectorial funciona bien.

    Una nota de producción: los ejemplos normalmente usan almacenamiento en memoria. Cámbialo por Cosmos DB o Blob antes de ponerlo en producción.

    1. Integración de ERP (SAP / Dynamics / Odoo)

    No dejes que los agentes llamen a los ERPs directamente. Pon una capa anti-corrupción en medio:

    • Un servicio de integración en C# que exponga un modelo contable canónico, para que los agentes no dependan del ERP
    • Azure API Management al frente para control de tráfico, caché y políticas — los ERPs rara vez toleran volumen de llamadas generado por agentes
    • Separación de lectura/escritura: lecturas síncronas; cualquier registro o escritura pasa por una cola de aprobación (Service Bus) con firma humana. Nada de registros iniciados directamente por agentes — el registro financiero vía orquestación no determinista es un problema de auditoría/SOX sin importar la calidad del modelo
    • Exponer cada ERP como una herramienta OpenAPI para que un solo patrón de autenticación y gobernanza cubra los tres

    Per-ERP specifics:

    • SAP — Logic Apps tiene un conector dedicado para SAP (BAPI/RFC/IDoc). Envuelve las transacciones específicas que necesites ("publicar asiento contable", "obtener partidas abiertas de proveedores") como flujos de trabajo individuales.
    • Dynamics 365 — API Web/OData de Dataverse, o el conector nativo de Logic Apps. Business Central tiene una superficie de API separada basada en AL.
    • Odoo — no hay conector de Microsoft de primera mano; espera trabajo personalizado. Ponle delante una Azure Function o un conector personalizado de Logic Apps sobre la API JSON-RPC/XML-RPC de Odoo, empaquetada detrás de una especificación OpenAPI para que funcione de manera idéntica a los otros. Por favor, presupuestalo — no está al mismo nivel que SAP/Dynamics.

    7. Identidad y seguridad

    • Identidades administradas para toda la autenticación de servicio a servicio: sin claves de API en la plataforma; las claves ignoran completamente RBAC. Ten en cuenta la advertencia de la documentación de que DefaultAzureCredential es conveniente para desarrollo, pero deberías usar una credencial específica (por ejemplo, ManagedIdentityCredential) en producción para evitar latencia, sondeos de credenciales no deseados y riesgo de fallback.
    • Flujo en nombre de (OBO) para que la identidad del usuario final llegue a AI Search. Este es el sutil: los equipos comúnmente hacen que los agentes consulten Search usando una identidad administrada compartida, lo que silenciosamente anula por completo el recorte a nivel de documentos. En una plataforma de contabilidad multi-cliente, eso es un tipo de error que filtra datos. Prueba esto de extremo a extremo antes que cualquier otra cosa.
    • Ingresa los roles/grupos de la app asignados a funciones contables (preparador, revisor, aprobador) para mantener la segregación de funciones.
    • Asigna RBAC de Foundry a nivel de proyecto en lugar de a nivel de recurso cuando puedas.
    • Endpoints privados en Foundry, AI Search, Cosmos DB y Key Vault; sin ingreso público. Claves gestionadas por el cliente si tu régimen de auditoría lo requiere.

    8. Observabilidad y evaluación (Foundry)

    Aquí es donde Foundry se gana su lugar más allá del hosting de modelos:

    • Seguimiento a través de los saltos de agentes — indispensable, porque las fallas en sistemas multiagente suelen ser fallas de enrutamiento, no del modelo. Para contabilidad, poder mostrar qué agente y qué herramienta produjo un número dado se acerca a un requisito de cumplimiento. Actívalo antes del lanzamiento, no después de que la auditoría lo pida.
    • Evaluaciones — crea un conjunto de datos de referencia con preguntas de contabilidad y respuestas verificadas, y ejecuta evaluaciones continuas (solidez, relevancia, calidad de recuperación) en CI. Programa re-ejecuciones para detectar desviaciones del modelo y de los prompts.
    • Application Insights + OpenTelemetry para medir latencia y costo por agente.
    • Filtros de contenido / salvaguardas configurados por despliegue.
    • Usa el catálogo de modelos de Foundry para comparar modelos candidatos con tus propios datos antes de comprometer uno por agente.

    9. Prácticas de despliegue y producción

    En lugar de diseñar desde cero, empieza con la arquitectura de referencia base de Microsoft para aplicaciones de chat/agente de Foundry y adáptala; ya incluye la configuración de red e identidad, que es la parte tediosa. Hay una variante de zona de aterrizaje si la estás desplegando en una zona de aterrizaje empresarial existente.

    • Azure Container Apps para el orquestador y los servicios de agente (scale-to-zero, escalado independiente por agente); AKS solo si ya lo estás usando; App Service para un front-end simple

    IaC con Bicep/Terraform, un entorno por etapa, desplegado vía GitHub Actions o Azure DevOps

    Throughput Provisionado (PTU) para picos predecibles a fin de mes; Standard para dev/test

    Capa de datos con redundancia por zona

    Sigue el costo por invocación de agente desde el principio — los sistemas con múltiples agentes multiplican el gasto de tokens sin que te des cuenta

    Pasa el diseño por la evaluación de cargas de trabajo AI del Well-Architected Framework antes de lanzarlo; está hecho exactamente para este tipo de sistemas no deterministas

    Fase sugerida

    1. Agente RAG único con recorte de seguridad probado de extremo a extremo (incluyendo OBO) — este pico reduce el riesgo de todo lo que viene después
    2. Agregar 2–3 agentes de dominio con transferencia
    3. Agregar lecturas de ERP
    4. Agregar escritura con aprobación HITL al final

    References

    Thanks,
    Manish.

    ¿Le ha resultado útil esta respuesta?

    1 persona ha encontrado útil esta respuesta.
    0 comentarios
  2. Darick Yael Gonzalez Mellado 0 Puntos de reputación
    2026-07-31T16:53:58.4933333+00:00

    Muchas gracias por la encomendacion y la manera de explicar detalladamente sobre la orquestacion de agentes en su maximo esplendor. de verdad muchas gracias por tan detallada la explicacion.

    ¿Le ha resultado útil esta respuesta?

    0 comentarios

Su respuesta

Las respuestas pueden ser marcadas como "Aceptadas" por el autor de la pregunta y "Recomendadas" por los moderadores, lo que ayuda a los usuarios a saber que la respuesta ha resuelto el problema del autor.