El cambio que importa
Un agente no pregunta como un buscador. Por eso la recuperación también tiene que evolucionar.
En un buscador tradicional, el usuario suele formular una intención relativamente acotada: encuentra una política, localiza una referencia, busca una cláusula o consulta un procedimiento. En un asistente o un agente, la pregunta puede ser mucho más compleja: “¿Qué riesgos contractuales tengo si renuevo este acuerdo teniendo en cuenta los anexos, la política interna, las incidencias de los últimos doce meses y las excepciones aprobadas?”. Eso ya no es una consulta. Es una pequeña investigación.
El RAG clásico suele enviar una consulta al sistema de búsqueda, recuperar un conjunto de fragmentos y pasar esos resultados al modelo generativo. La calidad depende de que la consulta inicial represente bien la necesidad, de que el índice tenga el contenido adecuado y de que la búsqueda —textual, vectorial o híbrida— encuentre los fragmentos correctos. Funciona muy bien en muchos escenarios y sigue siendo una arquitectura válida.
Agentic retrieval introduce una capa de planificación. El modelo puede descomponer una pregunta compleja en subconsultas más pequeñas, ejecutarlas en paralelo, combinar resultados, aplicar ranking semántico y devolver una respuesta estructurada con datos de grounding, referencias y metadatos de ejecución. El cambio no es únicamente técnico. Permite que el sistema interprete mejor qué información necesita buscar antes de generar una respuesta.
Pregunta simple
“¿Cuál es el periodo de preaviso de este contrato?” Una buena búsqueda híbrida sobre documentos bien indexados puede resolverla sin necesidad de planificación compleja.
Pregunta compleja
“Compara nuestras obligaciones de renovación, las excepciones del contrato, las incidencias críticas y el procedimiento interno y dime qué decisiones debe tomar Compras.” Aquí la descomposición en varias búsquedas puede mejorar cobertura y contexto.
La arquitectura en una frase
De “busca documentos parecidos” a “entiende qué información hace falta y organízala para responder”
Microsoft describe la recuperación agencial como una canalización de múltiples consultas. Puede utilizar un LLM para dividir la pregunta, incorporar historial conversacional, lanzar subconsultas en paralelo, volver a ordenar semánticamente los resultados y combinar las mejores evidencias. Esa respuesta puede entregarse a un agente o utilizar un modo de síntesis para generar directamente una contestación con citas.
Para conseguirlo aparecen nuevos objetos: fuentes de conocimiento, una base de conocimiento y la acción de recuperación. Las fuentes pueden ser índices ya existentes o, según capacidades disponibles, otras fuentes de conocimiento. El objetivo es que el agente no tenga que conocer cómo consultar cada repositorio por separado. Trabaja contra una capa de conocimiento.
Dónde vive la información
Índices, archivos, repositorios y otras fuentes que el sistema puede consultar como base de conocimiento empresarial.
Cómo se unifican y consultan
Agrupa fuentes y define el comportamiento de recuperación para que una misma consulta pueda trabajar con conocimiento distribuido.
Qué hay que buscar realmente
La pregunta se puede convertir en varias subconsultas enfocadas para mejorar cobertura y reducir dependencia de una única formulación.
Qué evidencia recibe el agente
Resultados consolidados, referencias de origen y metadatos de ejecución que permiten construir una respuesta más trazable.
Lo que no ha cambiado
Si la indexación es mala, agentic retrieval recuperará mejor… una base de conocimiento mediocre
La nueva capa de inteligencia no corrige una mala fuente de verdad. Si existen documentos duplicados, políticas obsoletas, permisos incorrectos, metadatos pobres o fragmentación mal planteada, el sistema seguirá teniendo un problema de conocimiento. Puede formular consultas más inteligentes, pero seguirá buscando en un repositorio que no merece confianza.
En RAG empresarial, la recuperación empieza mucho antes de la query. Hay que decidir qué fuentes se indexan, cómo se trocean los documentos, qué metadatos se conservan, cómo se representan versiones, cómo se eliminan documentos caducados, qué permisos se aplican, qué campos admiten filtros y qué contenido merece priorización. La arquitectura de búsqueda es inseparable del gobierno del conocimiento.
Microsoft sigue recomendando búsqueda híbrida como una pieza central porque combina coincidencia textual y búsqueda vectorial. Esto importa mucho en empresa: una consulta conceptual puede necesitar similitud semántica, pero un código de producto, una referencia contractual, una fecha, un número de expediente o una sigla interna se beneficia de coincidencias exactas. El vector no sustituye al texto. Se complementan.
Texto completo
Útil cuando el término exacto importa: referencias, nombres, códigos, fechas, acrónimos, cláusulas o terminología muy específica.
Vectorial
Útil para encontrar contenido conceptualmente relacionado aunque el usuario no utilice las mismas palabras que aparecen en el documento.
Híbrida
Ejecuta texto y vectores en paralelo y fusiona los resultados. Es una base especialmente sólida para escenarios RAG empresariales.
Ranking semántico
Ayuda a reordenar resultados para aumentar relevancia y reducir el ruido que llega al modelo generativo o al agente.
Dónde sí compensa
Cinco escenarios empresariales donde la recuperación agencial puede cambiar la calidad de la respuesta
Investigación de contratos y normativa
Una pregunta puede requerir contrato, anexos, políticas internas, normativa, versiones anteriores y excepciones. Dividir la consulta y recuperar de varias fuentes mejora cobertura y reduce la posibilidad de omitir una condición relevante.
Soporte técnico complejo
Resolver una incidencia puede exigir consultar manuales, base de conocimiento, histórico de tickets, versiones de producto y documentación específica del cliente. Una única consulta rara vez representa todo el problema.
RFP y licitaciones
El sistema necesita cruzar requisitos del pliego, referencias de proyectos, capacidades, acreditaciones, condiciones contractuales y documentación corporativa para preparar una respuesta consistente.
Agentes operativos
Antes de ejecutar una acción, el agente puede necesitar contexto de procedimiento, cliente, política, restricciones y antecedentes. Mejor recuperación significa mejores decisiones antes de automatizar.
Conocimiento transversal a varias áreas
Cuando la respuesta depende de contenido distribuido entre SharePoint, documentación técnica, políticas, bases de datos o conocimiento específico de diferentes equipos, una capa común de conocimiento puede reducir el acoplamiento entre el agente y cada fuente.
Dónde no lo forzaría
Cuatro casos donde un RAG clásico bien diseñado puede seguir siendo mejor
Microsoft recomienda considerar agentic retrieval en nuevas implementaciones orientadas a agentes y preguntas complejas, pero también mantiene el patrón clásico. Esa coexistencia tiene sentido. La decisión debe partir de calidad, latencia, coste, madurez y requisitos de producción.
Consultas muy simples y repetibles
Preguntas de catálogo, referencia, estado o procedimiento donde una búsqueda híbrida ya devuelve resultados excelentes y el patrón cambia poco.
Latencia crítica
Si cada milisegundo importa, añadir planificación con LLM puede penalizar tiempos. La arquitectura debe medir esa diferencia, no asumirla.
Necesidad de GA estricta
Algunas funciones de recuperación agencial están disponibles de forma general mediante API, mientras otras capacidades avanzadas siguen en preview. Producción regulada exige distinguirlas con precisión.
Orquestación propia consolidada
Si la organización ya tiene una capa de orquestación madura, métricas, routing y recuperación optimizada, migrar solo por novedad puede añadir trabajo sin retorno.
GA frente a preview
En 2026 hay que leer la letra pequeña antes de diseñar producción
Microsoft ha llevado parte de agentic retrieval a disponibilidad general mediante la API 2026-04-01. Sin embargo, la experiencia completa que se muestra en portal utiliza todavía capacidades de la API 2026-05-01-preview. Entre las funciones avanzadas pueden aparecer planificación de consultas, síntesis de respuesta o distintos niveles de esfuerzo de razonamiento según la versión utilizada.
Esto no es un detalle técnico menor. Un prototipo puede utilizar preview para validar un caso de uso, pero un sistema productivo con SLA, cumplimiento y soporte necesita saber exactamente qué componente está en GA y cuál no. Las funciones preview no ofrecen el mismo compromiso de servicio y pueden cambiar.
La recomendación práctica es diseñar una arquitectura donde el valor del caso de uso no dependa de una sola función experimental. Puede probarse la mejora de calidad con capacidades avanzadas y, en paralelo, mantener una ruta productiva basada en funciones soportadas cuando el riesgo lo exige.
Piloto
Puede explorar capacidades preview con métricas de calidad, coste y latencia, siempre dejando claro que el objetivo es aprender y validar.
Producción
Debe separar funciones GA de preview, revisar condiciones de servicio, seguridad, cumplimiento, límites y estrategia de evolución.
Coste y latencia
Más razonamiento puede mejorar la respuesta. También consume más tiempo y recursos.
Una arquitectura agentic puede incorporar llamadas de modelo para planificar la recuperación, generar subconsultas y, en determinados modos, sintetizar la respuesta. Cada capa adicional tiene un coste y una latencia. Por eso no basta con comparar “calidad de respuesta”. Hay que medir el valor marginal de esa calidad.
Azure AI Search permite configurar distintos niveles de esfuerzo de razonamiento en capacidades que lo soportan. La idea es útil: no todas las consultas necesitan la misma profundidad. Una pregunta sencilla puede resolverse con esfuerzo mínimo; una investigación compleja puede justificar un modo más profundo. Esa adaptación puede ser más eficiente que ejecutar siempre la configuración más costosa.
En empresa, la métrica correcta no es “cuántas subconsultas ejecutamos”. Es si aumentó la tasa de respuesta correcta, si mejoró la cobertura, si las citas son más relevantes, si bajó el retrabajo del usuario y si el tiempo total sigue siendo aceptable para el proceso. Una arquitectura más avanzada solo es mejor si mueve esas métricas.
| Métrica | Qué medir | Por qué importa |
|---|---|---|
| Relevancia | Si los fragmentos recuperados contienen realmente la evidencia necesaria. | Una respuesta elegante con contexto equivocado sigue siendo incorrecta. |
| Cobertura | Si se recuperan todas las partes importantes de una pregunta compleja. | Es una de las áreas donde la descomposición en subconsultas puede aportar valor. |
| Latencia | Tiempo desde la consulta hasta el resultado utilizable. | Una respuesta mejor pero demasiado lenta puede fracasar en operación. |
| Coste por tarea | Búsqueda, modelos, almacenamiento y procesamiento asociados a cada interacción. | Permite decidir dónde merece la pena la capa agentic y dónde no. |
Seguridad y conocimiento
El agente no debería descubrir más información de la que el usuario podría consultar por sí mismo
Cuanto más útil se vuelve un agente, más fuentes quiere consultar. Y cuanto más conocimiento consulta, más importante es la seguridad. No basta con indexar información corporativa y confiar en que la aplicación “sepa” qué puede mostrar. Permisos, filtros, identidad, fronteras de datos y trazabilidad tienen que formar parte del diseño de recuperación.
La documentación reciente de Microsoft subraya además que las bases de conocimiento pueden conectarse a fuentes diferentes y que el cliente es responsable de revisar implicaciones de datos, cumplimiento, límites geográficos y permisos. Esta responsabilidad aumenta cuando se incorporan fuentes remotas o contenidos que pueden tener reglas distintas.
El principio debe ser simple: la IA no crea una excepción de seguridad. Si el usuario no debería ver un documento, el agente tampoco debería utilizarlo como grounding. Y si la respuesta se utiliza para ejecutar una acción, el control debe extenderse también a la autorización de esa acción.
Permisos en origen
Definir qué contenido es visible según identidad, grupo, función, proyecto, país, cliente o nivel de confidencialidad.
Trazabilidad
Conservar referencia a las fuentes utilizadas para poder revisar por qué el sistema respondió de una determinada forma.
Gobierno de conocimiento
Caducidad, versiones, fuentes prioritarias y responsabilidad sobre contenido deben mantenerse igual que cualquier dato crítico.
Evaluación continua
Probar preguntas reales, errores conocidos, ataques de prompt, respuestas sin evidencia y escenarios de permisos antes de escalar.
Ruta de decisión
Cómo decidir si migrar un RAG existente hacia agentic retrieval
No empezaría tocando código. Empezaría comparando los fallos actuales. Si el RAG ya recupera bien y los usuarios hacen preguntas simples, quizá no haya problema que resolver. Si falla por preguntas compuestas, cobertura insuficiente, necesidad de varias fuentes o pérdida de contexto conversacional, sí existe una hipótesis clara que probar.
Construir un set de preguntas reales
Preguntas simples, ambiguas, compuestas, de varias fuentes y con contexto conversacional. Sin un benchmark no hay comparación seria.
Medir el RAG actual
Relevancia, cobertura, precisión, citas, latencia, coste y satisfacción. Documentar dónde falla antes de cambiar arquitectura.
Probar agentic retrieval sobre el mismo benchmark
No comparar demos diferentes. Misma fuente, mismas preguntas y métricas para aislar el valor de la nueva recuperación.
Separar calidad de coste
Una mejora de cinco puntos puede ser fantástica o irrelevante dependiendo del proceso, número de usuarios y coste adicional.
Migrar solo los escenarios que ganan
No es obligatorio uniformar toda la plataforma. Una empresa puede mantener RAG clásico para búsquedas sencillas y utilizar recuperación agencial en asistentes de investigación o agentes que necesitan una capa de conocimiento más sofisticada.
Ecosistema Microsoft
Azure AI Search deja de ser “el buscador detrás del chatbot” y se acerca a una capa de conocimiento para agentes
La evolución de Azure AI Search encaja con una arquitectura Microsoft más amplia. Microsoft Foundry aporta modelos y experiencias de creación de agentes. Azure AI Search aporta recuperación, índices, ranking y conocimiento. Azure OpenAI y otros modelos aportan razonamiento y generación. Power Platform y Copilot Studio pueden convertir ese conocimiento en experiencias y automatizaciones cercanas al negocio.
La oportunidad no consiste en crear una base de conocimiento diferente para cada agente. Consiste en construir capacidades reutilizables. Si varios agentes necesitan consultar políticas, documentación técnica, propuestas, contratos o procedimientos, una capa de conocimiento gobernada puede convertirse en activo común.
Ahí es donde Azure AI Search gana relevancia estratégica: no solo como servicio de búsqueda, sino como pieza para conectar contenido empresarial con agentes que necesitan recuperar información precisa antes de recomendar, decidir o actuar.
Azure AI Search
Recuperación textual, vectorial, híbrida, semántica y agentic sobre conocimiento empresarial.
Microsoft Foundry
Modelos, agentes, evaluación y servicios para llevar soluciones de IA hacia producción.
Copilot Studio
Agentes y experiencias empresariales conectadas a datos, acciones y procesos de Microsoft.
Power Platform
Automatización y aplicaciones para convertir conocimiento recuperado en ejecución controlada.
La capa que más se subestima
Diseñar una knowledge base no consiste en conectar carpetas: consiste en decidir qué conocimiento merece gobernar una respuesta
Cuando una organización empieza a trabajar con agentes, aparece una tentación comprensible: conectar cuantos más repositorios mejor. SharePoint, documentación técnica, PDFs, tickets, contratos, bases de datos, wikis, expedientes y cualquier carpeta que pueda aportar contexto. Técnicamente puede ser posible. Estratégicamente puede ser una mala idea. Una base de conocimiento útil no es la que contiene más documentos, sino la que permite distinguir qué fuente es válida, actual, relevante y autorizada para cada tipo de pregunta.
Esto obliga a introducir reglas que normalmente no existen en un buscador sencillo. ¿Qué ocurre si dos políticas se contradicen? ¿Cuál tiene prioridad? ¿Cómo sabe el agente que un documento de 2023 ha sido sustituido por otro de 2026? ¿Qué metadato identifica una versión vigente? ¿Cómo se separa documentación comercial de normativa interna? ¿Qué ocurre con anexos asociados a un contrato principal? Si estas decisiones no se resuelven en la capa de conocimiento, el modelo generativo tendrá que inferirlas a partir de fragmentos, y esa es una base débil para automatizar decisiones.
Una buena arquitectura suele empezar clasificando fuentes por autoridad. Por ejemplo, una política corporativa aprobada puede tener mayor peso que una presentación interna; una ficha maestra de producto debe prevalecer sobre una propuesta comercial antigua; una cláusula contractual firmada tiene más autoridad que un borrador. Esa jerarquía puede reflejarse mediante metadatos, filtros, reglas de indexación, diseño de consultas y, cuando sea necesario, lógica de aplicación.
Agentic retrieval puede mejorar cómo se explora el conocimiento, pero no debería convertirse en una excusa para evitar este trabajo. Cuanto más autónomo sea el agente, más importante es que la base sobre la que razona tenga una estructura defendible. Un agente que recupera muy bien información contradictoria sigue necesitando reglas para saber qué hacer con ella.
Autoridad
Qué fuente debe considerarse oficial cuando varias contienen información sobre el mismo proceso, producto, cliente o política.
Vigencia
Cómo identificar contenido actual, versiones sustituidas, borradores, anexos y documentos que ya no deberían participar en una respuesta.
Seguridad
Qué usuarios, grupos o agentes pueden recuperar cada fragmento y qué controles deben mantenerse al combinar varias fuentes.
Observabilidad
Qué consulta se generó, qué fuente respondió, qué fragmentos entraron en el contexto y dónde se originó una respuesta incorrecta.
Un piloto que realmente demuestra algo
No compares demos. Compara respuestas sobre preguntas que hoy hacen perder tiempo a tu organización.
La mayoría de pruebas de RAG parecen buenas cuando se preparan cinco preguntas fáciles y una carpeta con documentación limpia. Ese escenario demuestra que la tecnología funciona, pero dice poco sobre si funcionará en producción. Un piloto serio necesita preguntas que representen ambigüedad, documentación incompleta, varias fuentes, versiones contradictorias, permisos y consultas que obliguen al sistema a buscar más de una pieza de evidencia.
Para comparar RAG clásico y agentic retrieval, conviene construir un banco de evaluación con respuestas esperadas y criterios explícitos. No siempre tiene que existir una frase exacta como “respuesta correcta”. En investigación empresarial puede ser más útil definir qué hechos son obligatorios, qué fuentes deberían citarse, qué errores serían críticos y qué nivel de cobertura se considera suficiente.
Después, las dos arquitecturas deben enfrentarse al mismo set. Si agentic retrieval mejora preguntas complejas pero añade latencia a las simples, quizá el resultado no sea sustituir un patrón por otro, sino enrutar cada consulta al mecanismo adecuado. Esa arquitectura híbrida puede ser más eficiente y más fácil de justificar económicamente.
| Tipo de prueba | Ejemplo | Qué debería demostrar |
|---|---|---|
| Exacta | “¿Cuál es el límite de aprobación de compras en España?” | Precisión, fuente correcta y baja latencia. |
| Compuesta | “Compara política global, excepción local y contrato de proveedor.” | Descomposición, cobertura y combinación de evidencias. |
| Conflictiva | Dos documentos contienen condiciones diferentes. | Capacidad de identificar conflicto y no inventar una síntesis. |
| Con permisos | La fuente relevante no está autorizada para ese usuario. | Que la recuperación respete la frontera de seguridad. |
| Conversacional | La segunda pregunta depende del contexto de la primera. | Uso correcto del historial sin contaminar nuevas búsquedas. |
Errores de modernización
Seis maneras de complicar un RAG que ya funcionaba sin obtener una mejora real
Migrar porque “agentic” es la nueva palabra
Si no existe un fallo medible en recuperación, contexto o cobertura, todavía no existe una razón técnica ni económica para cambiar.
Mantener el mismo índice deficiente
Cambiar la capa de consulta sin revisar fragmentación, metadatos, duplicidades y documentos obsoletos limita rápidamente la mejora posible.
Usar máximo razonamiento para todo
La complejidad debe adaptarse a la consulta. Ejecutar siempre el modo más profundo puede penalizar coste y experiencia sin aportar precisión.
Ignorar preview frente a GA
Una PoC puede aceptar más riesgo tecnológico. Un sistema crítico necesita conocer exactamente qué versión, API y funcionalidad están soportadas.
No conservar telemetría de recuperación
Si no sabes qué subconsultas se generaron y qué fragmentos fueron recuperados, depurar una respuesta mala se convierte otra vez en intuición.
Confundir mejor recuperación con autorización para actuar
Que el agente entienda mejor el contexto no significa que deba poder ejecutar cualquier acción. Recuperación, decisión y autorización necesitan controles separados.
Checklist antes de producción
Ocho respuestas que deberían estar cerradas antes de poner un agente sobre conocimiento corporativo
Una prueba puede demostrar relevancia en pocos días. Producción exige algo más: saber quién es propietario del contenido, cómo se actualiza, qué permisos se respetan, qué versión de las APIs se utiliza, cuánto cuesta cada interacción y qué ocurre cuando no existe evidencia suficiente. Si cualquiera de estas respuestas depende de “ya lo veremos”, el problema no es el modelo. Es la arquitectura operativa.
Preguntas frecuentes
Agentic retrieval, RAG y Azure AI Search en 2026
¿Qué es agentic retrieval en Azure AI Search?
Es una canalización de recuperación diseñada para RAG y agentes que puede descomponer preguntas complejas en subconsultas, ejecutarlas, reordenar resultados y devolver grounding estructurado con referencias.
¿Sustituye al RAG clásico?
No en todos los casos. Microsoft mantiene ambos patrones. El clásico puede ser más simple y rápido; agentic retrieval es especialmente interesante para preguntas complejas, conversacionales y escenarios de agentes.
¿Agentic retrieval está disponible de forma general?
Algunas capacidades están disponibles mediante la API 2026-04-01, mientras que la funcionalidad avanzada completa continúa utilizando elementos preview en la API 2026-05-01-preview. Conviene validar cada función antes de producción.
¿Sigue siendo importante la búsqueda híbrida?
Sí. La combinación de texto completo y vectores sigue siendo especialmente útil en empresa porque mezcla coincidencia conceptual con precisión sobre términos exactos, códigos, fechas y nomenclaturas.
¿Necesito varias fuentes de conocimiento?
No necesariamente. Una única fuente bien gobernada puede ser suficiente. La ventaja aparece cuando el caso de uso realmente depende de contenido distribuido o de varias áreas.
¿Aumenta el coste?
Puede hacerlo porque añade razonamiento y más trabajo de recuperación. Por eso la comparación debe medir coste por tarea, latencia y mejora real de calidad.
¿Qué debería medir en un piloto?
Relevancia, cobertura, precisión, calidad de citas, latencia, coste, tasa de respuestas útiles y reducción de retrabajo del usuario.
¿Es útil para agentes que ejecutan acciones?
Sí, especialmente cuando el agente necesita comprender políticas, contexto o antecedentes antes de actuar. La recuperación no sustituye la autorización de la acción; ambas capas deben diseñarse por separado.
Navegación recomendada
Cómo encaja esta pieza en la arquitectura Azure + IA de Ayesa365
Azure AI Search para empresas
La página principal para entender búsqueda, conocimiento corporativo y grounding empresarial.
RAG empresarial
Qué es RAG, cuándo utilizarlo y cómo conectar modelos con información corporativa.
Azure + IA empresarial
Arquitectura para datos, modelos, agentes, integración, seguridad y automatización.
Microsoft Foundry
Modelos, agentes y servicios para llevar IA empresarial hacia producción con control.
Ayesa · Microsoft
La tecnología importa. La capacidad de conectar arquitectura, proceso y operación importa más.
Ayesa trabaja sobre el ecosistema Microsoft con capacidades que abarcan Business Applications, Azure, datos, Power Platform, Microsoft 365, seguridad e IA. Ese enfoque permite revisar cada decisión dentro de una arquitectura empresarial completa, evitando optimizar una pieza a costa de crear un nuevo silo.
Designaciones, especializaciones y certificaciones sirven como señal de capacidad, pero el criterio relevante para un proyecto es cómo se convierten en una solución gobernable, mantenible y alineada con los procesos reales del cliente.
Fuentes Microsoft
Documentación oficial para profundizar
Azure AI Search y RAG empresarial
¿Tu RAG necesita más inteligencia o simplemente una mejor base de conocimiento?
Podemos comparar la calidad de tu recuperación actual, revisar índices, búsqueda híbrida, seguridad y arquitectura y determinar dónde agentic retrieval puede mejorar respuestas y dónde solo añadiría complejidad.
¿Conectamos?
La tecnología bien aplicada suele facilitar las cosas. Si sospechas que también puede ser de ayuda para ti, concédenos la oportunidad de conocerte y demostrarte hasta qué punto es así.
Suscríbete a nuestra enews mensual, y no te pierdas los mejores contenidos sobre Microsoft Dymanics 365
Información respecto al tratamiento de los datos solicitados, de acuerdo con el RGPD 2016/679 y la LOPDGDD 3/2018: el responsable es Ibermática SA; la finalidad es la recogida y tratamiento de los datos personales que solicitamos para atender tu consulta, enviarte nuestras publicaciones, newsletters, promociones de productos y/o servicios, y recursos exclusivos; la legitimación se establece mediante el consentimiento expreso; no se cederán datos a terceros, salvo obligación legal; en cualquier momento puedes ejercer tus derechos de acceso, rectificación, supresión, portabilidad, limitación u oposición al tratamiento de tus datos, así como retirar el consentimiento prestado o formular reclamaciones ante la Autoridad de Control, enviando la solicitud por correo electrónico a: arco@ibermatica.com; puedes consultar la información adicional y detallada sobre Privacidad y Protección de Datos de Carácter Personal en la Política de Privacidad de Ibermática S.A.
¿Por qué Ayesa?
Somos uno de los principales implantadores de Microsoft, con casi 2000 clientes que han depositado su confianza en nosotros para la implantación de Dynamics 365, Business Central (NAV / Navision) y Dynamics 365 Finance & Operations (AX / Axapta). Además, destacamos en el despliegue de proyectos sobre AZURE y Microsoft 365. Nuestra experiencia en el campo de la inteligencia artificial y el uso de Copilot nos sitúa a la vanguardia de la innovación tecnológica.
Con una plantilla de más de 12.000 profesionales y una sólida presencia en 23 países, estamos comprometidos en ayudar a nuestros clientes a definir y aprovechar oportunidades en el nuevo contexto digital. Desde la tecnología hasta las personas, ofrecemos un enfoque integral que garantiza el éxito en cada proyecto.
- ÚLTIMAS ENTRADAS DEL BLOG -
Business Development Manager | PSELLER Microsoft en Ayesa | Miembro Unidad Transición Energética, Climática y Urbana en Tecnalia | Secretaria de la Junta Directiva del Cluster de la Construcción (Build INN)