Marketplace interno de agentes de IA: guía empresarial para 2026
Los empleados ya crean agentes para investigación, propuestas, soporte, finanzas y operaciones internas. El siguiente problema no es crear otro agente. Es conseguir que cada persona encuentre el adecuado, sepa si está aprobado, lo conecte al contexto de la empresa sin saltarse permisos y pueda identificar a su responsable cuando algo cambie.
Un marketplace interno de agentes de IA resuelve ese problema de distribución. Bien diseñado, combina catálogo, flujo de aprobación y plano de control operativo. Mal diseñado, es una página de enlaces que facilita encontrar IA en la sombra. Esta guía aborda la infraestructura que separa ambos resultados y complementa nuestra guía para adoptar IA dentro de la empresa.
¿Qué es un marketplace interno de agentes de IA?
Un marketplace interno de agentes de IA es un catálogo empresarial gobernado donde los empleados descubren y solicitan agentes aprobados para trabajos concretos. Cada ficha vincula la descripción para el usuario con contexto corporativo, reglas de acceso, un responsable, evidencia de evaluación, uso, coste y estado del ciclo de vida. A diferencia de un directorio público, distribuye agentes dentro de un límite de confianza existente.
| Capa | Usuario principal | Pregunta que responde |
|---|---|---|
| Marketplace público de agentes | Compras o desarrollo | ¿Qué agentes externos podemos evaluar o comprar? |
| Marketplace interno de agentes | Empleado y responsable de equipo | ¿Qué agente aprobado puede ayudarme con este trabajo? |
| Registro y plano de control | TI, seguridad y plataforma | ¿Qué existe, a qué accede, quién responde y funciona correctamente? |
Las tres capas pueden compartir metadatos, pero no son intercambiables. Una tienda atractiva sin registro no demuestra propiedad ni permisos. Un registro sin una experiencia útil da visibilidad a TI, pero no mejora la adopción. El sistema valioso conecta ambos lados.
¿Por qué las tiendas empresariales de agentes se convirtieron en infraestructura real en 2026?
La categoría emerge porque la creación de agentes se ha descentralizado, pero la responsabilidad no desaparece. Microsoft describe cómo empleados de distintas funciones y niveles técnicos crean agentes, con controles integrados, supervisión de TI y formación en su experiencia interna gobernando agentes a escala. Ya no se trata de un único equipo de innovación publicando software para todos.
La distribución también entra en las herramientas donde ya se trabaja. En el diseño de Agent Gallery de Google Cloud para 2026, los empleados exploran agentes de socios y solicitan acceso, mientras los administradores conservan el control del despliegue, según el anuncio del marketplace de Gemini Enterprise. La interfaz parece una tienda de aplicaciones, pero el mecanismo importante es la ruta de solicitud y aprobación.
También hay ejemplos públicos de empresas que aplican el patrón a su propia plantilla. Tata Elxsi afirma en su informe anual 2025 a 2026 que su marketplace interno selecciona agentes listos para producción y fomenta su reutilización en delivery, calidad, TI, marketing, legal, recursos humanos y formación. La afirmación aparece junto a infraestructura, controles y capacitación por roles en el informe anual presentado por la empresa.
La escala hace inevitable un registro. Gartner prevé que una empresa global media del Fortune 500 podría usar más de 150.000 agentes en 2028, mientras solo el 13 por ciento de las organizaciones consultadas considera adecuada su gobernanza. Una previsión no es un resultado medido, pero la respuesta recomendada es concreta: inventario central, identidad, permisos, ciclo de vida, gobierno de la información y supervisión continua en su guía de abril de 2026 sobre la proliferación de agentes.
¿Qué arquitectura necesita un marketplace interno?
El marketplace es la vista para empleados sobre un registro gobernado. El registro es la fuente de verdad. La búsqueda, las recomendaciones y las colecciones por equipo son proyecciones de ese registro. El runtime no tiene que pertenecer al mismo producto, pero cada ejecución debe apuntar a una versión registrada.
- Catálogo y descubrimiento: fichas buscables por trabajo, departamento, sistema, sensibilidad de datos y aprobación. Use lenguaje de tarea, como «preparar un informe de renovación», no lenguaje de framework.
- Identidad y acceso: una identidad de máquina distinta para cada agente desplegado, un patrocinador humano, acceso por rol y permisos mínimos para herramientas. El agente no debe heredar todos los permisos de quien lo publicó.
- Contexto empresarial: conectores a fuentes aprobadas que preservan permisos en cada recuperación. El contexto no es una base vectorial común que aplana los derechos de SharePoint, Confluence, Drive y CRM.
- Evaluación y certificación: pruebas específicas de la tarea, comprobaciones de llamadas a herramientas, pruebas de seguridad, nivel de riesgo y aprobación ligados a una versión. El sello debe caducar tras un cambio material.
- Gateway de políticas: control antes de ejecutar herramientas, con scopes, prevención de fuga de datos, aprobación humana para escrituras relevantes, límites de uso y sandbox cuando corresponda.
- Observabilidad y economía: trazas, tasas de éxito y escalado, latencia, coste por resultado aceptado, incidentes y feedback. El gasto en tokens no indica por sí solo si se ahorra trabajo.
- Ciclo de vida: estados de borrador, revisión, aprobado, restringido, obsoleto y retirado, además de una fecha de revisión. Un agente sin dueño o con contexto antiguo es deuda operativa.
La documentación actual del Agent Store de Microsoft expone los mismos requisitos en forma específica para su plataforma. Los administradores pueden revisar editor, capacidades, conocimiento, acciones, seguridad, cumplimiento, certificación y actividad antes de asignar un agente a usuarios o grupos. También admite agentes de la organización y de plataformas externas. Por eso, el modelo administrativo de Microsoft 365 Agent Store sirve como lista de requisitos incluso para otras arquitecturas.
¿Qué debe contener cada ficha de agente?
Una ficha es un contrato operativo, no publicidad. Si una persona no puede anticipar qué leerá, cambiará y devolverá el agente, la ficha está incompleta.
| Campo | Ejemplo | Por qué importa |
|---|---|---|
| Trabajo y límite | Redacta un informe de renovación, nunca lo envía | Define resultado útil y autonomía |
| Responsable y patrocinador | Operaciones de ingresos, rol identificado | Crea una vía de escalado y revisión |
| Entradas y fuentes | Oportunidades del CRM y notas aprobadas | Hace visible el contexto |
| Acciones y permisos | Lee CRM, crea documento, no envía correo | Explica el impacto posible |
| Estado de evaluación | 92 de 100 casos aceptados, revisión el 4 de agosto | Convierte «aprobado» en evidencia |
| Coste y objetivo de servicio | Menos de 0,40 EUR por informe aceptado | Ayuda a enrutar y retirar |
| Versión y cambios | v1.4, modelo y herramienta CRM actualizados | Evita cambios silenciosos |
| Feedback e incidentes | Notificar salida errónea o acción insegura | Cierra el ciclo operativo |
Preservar permisos de origen es la parte más subestimada del contexto corporativo. Nuestra guía de RAG con permisos en SharePoint, Confluence y Google Drive explica el plano de datos. Para agentes que llaman herramientas internas, el límite de identidad pertenece al gateway, como muestra nuestra arquitectura de autorización MCP empresarial.
¿Cómo debe funcionar la publicación y aprobación?
Use carriles según el riesgo, no una única cola. Un resumidor personal de solo lectura sobre documentos propios no debe esperar detrás de un agente capaz de aprobar reembolsos o modificar registros de RR. HH. A la vez, «creado internamente» no demuestra seguridad.
- Registrar: el creador declara propósito, responsable, usuarios, fuentes, herramientas, modelo, autonomía y valor esperado.
- Clasificar: reglas asignan un riesgo provisional según datos, capacidad de escritura, comunicación externa e impacto de decisión.
- Probar: evaluaciones automáticas y pruebas de seguridad se ejecutan contra una versión. Los casos de alto impacto añaden revisión del dominio y legal.
- Aprobar y limitar: se publica para un grupo definido con permisos temporales, presupuestos y puntos de control humano.
- Observar: se registran resultados, acciones denegadas, correcciones, incidentes, latencia y coste.
- Revisar o retirar: los cambios materiales obligan a reevaluar. Los agentes sin uso, sin dueño o con fallos constantes salen de la tienda.
El Model AI Governance Framework for Agentic AI de IMDA, Singapur, ofrece una referencia actual. Pide evaluar y acotar riesgos desde el principio, mantener una responsabilidad humana significativa, aplicar controles técnicos y pruebas, supervisar tras el despliegue y promover un uso responsable. También recomienda autorizaciones acotadas, mínimas y temporales. Esos principios se convierten directamente en puertas del marketplace en el marco de gobernanza para IA agéntica de enero de 2026.
¿Comprar una plataforma, ampliar la suite actual o construir?
| Enfoque | Encaja cuando | Principal contrapartida |
|---|---|---|
| Ampliar Microsoft, Google, Salesforce, ServiceNow u otra suite | Identidad, datos y mayoría de agentes viven en un ecosistema | Adopción rápida, pero gobierno condicionado por la plataforma |
| Usar un registro o plano de control específico | Los agentes abarcan varios runtimes y sistemas | Más visibilidad transversal, con otro componente operativo |
| Crear un marketplace interno ligero | El flujo, despliegue o límite regulado es particular | Ajuste y propiedad exactos, pero el ciclo de vida queda a su cargo |
| Empezar por un directorio curado | Hay menos de unos diez agentes y falta validar demanda | Aprendizaje barato, pero no sustituye gobierno en runtime |
No empiece por capturas de la tienda. Inventaríe agentes, proveedores de identidad, datos, runtimes y obligaciones de aprobación. Si una suite cubre la mayor parte del grafo, amplíela. Si no, mantenga un registro neutral y publique en las superficies donde ya se trabaja. Nuestra guía de software a medida frente a software estándar estructura la propiedad y el lock-in.
¿Cómo es un despliegue práctico de 90 días?
La primera versión útil no es un bazar para toda la empresa. Es un catálogo pequeño con una ruta fiable de publicación y dos o tres agentes para trabajo repetido.
- Días 1 a 15, inventario y selección: descubrir agentes existentes y flujos en la sombra, elegir un departamento, definir la ficha, nombrar responsables y seleccionar dos trabajos medibles de riesgo bajo o medio.
- Días 16 a 35, registro: implementar SSO, roles, esquema de catálogo, búsqueda, solicitudes y estados básicos. Conectar una superficie de trabajo existente.
- Días 36 a 60, certificación: preservar permisos, añadir conjuntos de evaluación, probar límites, definir aprobación humana y capturar trazas de coste y resultado. Use nuestra lista de seguridad para evaluación y sandbox de agentes.
- Días 61 a 75, piloto controlado: publicar para uno o dos grupos y observar búsquedas fallidas, denegaciones, abandonos, correcciones y soporte. Arreglar el flujo antes de ampliar inventario.
- Días 76 a 90, decidir qué escala: publicar métricas, retirar agentes débiles, documentar la aprobación y abrir un proceso repetible para nuevos equipos.
¿Qué métricas demuestran valor?
- Éxito de descubrimiento: búsquedas que terminan en un agente adecuado.
- Activación y uso retenido: usuarios aprobados que completan una tarea y vuelven.
- Resultados aceptados: salidas usadas sin una corrección importante, por versión.
- Intervención y escalado humano: una señal de seguridad y ajuste, no siempre un fallo.
- Coste por resultado aceptado: costes de modelo, herramientas y plataforma divididos por trabajo aprovechado.
- Reutilización y consolidación: equipos atendidos por agentes comunes y duplicados retirados.
- Tiempo de gobernanza: desde la solicitud hasta una decisión proporcional al riesgo.
¿Cuándo tiene sentido contratar la implantación?
Tiene sentido cuando ya existen agentes en varios departamentos, no se distingue qué está aprobado, las revisiones de seguridad empiezan siempre desde cero o buenos prototipos se frenan antes de distribuirse. Es pronto si no hay un caso repetido, un responsable del proceso ni fuentes listas para acceso controlado.
Nuestro servicio de AI Enablement puede cubrir inventario, arquitectura, MVP del marketplace, integración de contexto e identidad, puertas de evaluación, observabilidad y traspaso al equipo. El primer proyecto debe dejar un sistema propio y un modelo operativo repetible. Para evaluar la madurez, solicite una sesión de alcance para flujos internos y marketplace de agentes.
Preguntas frecuentes
¿Una tienda interna de agentes es lo mismo que un marketplace?
En búsquedas empresariales, los términos se solapan. «Tienda» destaca descubrimiento y distribución. «Marketplace» puede incluir proveedores externos, compras o precios. Defina el producto por sus controles: catálogo interno, publicadores aprobados, acceso acotado, evaluación, responsables y ciclo de vida.
¿Cada empleado necesita un agente personal?
No. Empiece por trabajos repetidos y agentes compartidos bajo una función. Los agentes personales ayudan, pero el marketplace aporta más cuando un flujo validado captura conocimiento y sirve a un grupo sin ampliar permisos.
¿Podemos usar contexto empresarial sin copiar todos los datos?
Sí. Recupere desde los sistemas de origen en cada ejecución, conserve sus controles, minimice lo indexado y entregue solo el contexto necesario. El marketplace describe las fuentes y el plano de datos aplica los derechos.
¿Basta con Microsoft 365 o Gemini Enterprise?
Puede bastar si identidad, datos, creación de agentes y trabajo diario viven en ese ecosistema. Una organización multi-cloud o regulada puede necesitar además un registro neutral, gateway de políticas y observabilidad.
¿Qué incluye el primer MVP?
SSO, fichas buscables, responsables y versiones, solicitudes por grupos, estado de evaluación, dos o tres agentes productivos, trazas básicas, costes, feedback y retirada. Las recomendaciones, valoraciones y cientos de fichas pueden esperar.
Reflexiones finales
Un marketplace interno de agentes de IA no es principalmente una tienda. Es la interfaz para empleados de un modelo operativo de agentes. El catálogo permite descubrir capacidades aprobadas. El registro, la identidad, el contexto con permisos, las evaluaciones, el gateway de políticas, la observabilidad y el ciclo de vida hacen que sean reutilizables con confianza. Empiece con dos o tres trabajos repetidos, publique evidencia en vez de simples sellos, mida resultados aceptados en vez de número de agentes y retire lo que no mantenga la confianza.
