Marketplaces de plugins: cómo dar gobierno al tooling de IA sin frenar a los equipos

Este artículo abre una serie de tres sobre cómo llevar el tooling de IA de los equipos de desarrollo al mismo nivel de control que el resto del software que usan. Es el resultado de lo que hemos aprendido montando un marketplace de plugins interno para GitHub Copilot y Claude con varios equipos, tanto de nuestros clientes como de la propia qualtio:

• Marketplaces de plugins (este artículo): qué es un marketplace de plugins y qué aporta a mi modelo de gobernanza de IA.
• Plugins para GitHub Copilot y Claude: anatomía de un plugin multicliente: cómo construir un plugin que funcione en varios asistentes.
• Plugins para GitHub Copilot y Claude: estrategia de validación, instrumentos y coste: cómo asegurar que un cambio en un plugin funciona como se espera y no rompe nada antes de publicarlo.

En este primer post veremos por qué el tooling que cada desarrollador se monta por su cuenta es una forma de shadow AI difícil de medir y mantener, dónde encajan los marketplaces de plugins dentro de un gobierno de IA y qué posibilidades nos abren para crear, validar y distribuir nuestros assets de IA tal y como hacemos con otros proyectos de código.

Contexto y motivo: el shadow AI que sabemos que existe pero no queremos ver

Shadow AI se conoce como el uso no autorizado, no medido o no aprobado de herramientas de IA. Pegar información en chats públicos o de suscripciones personales, usar modelos de diferentes proveedores, descargar y/o compartir skills o instructions de repositorios públicos o usar MCPs no validados por la organización son ejemplos claros de ello. El informe de IBM de 2026 encuentra shadow AI en el 43 % de las brechas de seguridad analizadas (más del doble que el año anterior) y cada una de esas brechas cuesta de media 5,39 millones de dólares, 400.000 más que la media de todas las brechas analizadas (4,99 millones).

Fuente: IBM, Cost of a Data Breach Report 2026

En una organización que ya ha desplegado Copilot o Claude con licencias corporativas ese problema está parcialmente acotado pero hay otros que escapan rápidamente al control de una organización debido a la gran competencia en asistentes de IA actual y las infinitas posibilidades que brindan a los usuarios.

En cualquier equipo de desarrollo que use asistentes de IA es habitual encontrarte con escenas de este tipo:

• Prompts que viajan por Slack

  Una persona ha escrito un CLAUDE.md excelente para el microservicio que mantiene y otra tiene una carpeta de prompts que funcionan bien y que comparte por Slack cuando alguien pregunta.

• Un MCP con el token en local

  Un tercero ha configurado un servidor MCP que apunta a la API interna de gestión de incidencias con un token en un fichero de configuración local.

• Plugins de un hilo de Reddit

  Alguien más ha instalado tres plugins de un repositorio de GitHub que encontró en (por ejemplo) un hilo de Reddit.

Nada de eso está inventariado y nadie sabe qué instrucciones recibe el asistente que escribe código que acaba en producción.

Esto también es shadow AI y cuesta dinero por varias vías. Primero, se pierde conocimiento ya que el criterio experto que alguien codificó en un prompt vive en su portátil y no se versiona ni se hereda. Segundo, se pierde también el estándar cuando cinco equipos acaban generando tests de cinco maneras distintas pese a que la IA debería acercar las formas de trabajar. Y tercero, está la superficie de ataque. Un plugin puede traer hooks que ejecutan comandos automáticamente en cada evento y servidores MCP que hablan con el exterior. Con el modo autopilot activo el usuario ni siquiera aprueba esas llamadas.

La respuesta instintiva de muchas organizaciones es prohibir y esto no creemos que sea una buena idea. Los equipos pierden una herramienta que funciona y encima el shadow AI se vuelve más discreto o incluso clandestino porque la IA se puede utilizar por otras vías u otros proveedores que tu compañía no ha verificado ni tiene contrato alguno. A continuación veremos que lo que llevamos décadas aplicando a las dependencias de software (un repositorio corporativo, versiones, changelogs, validaciones, control de acceso y distribución) es perfectamente aplicable al tooling de inteligencia artificial que utilizamos en nuestro día a día y la pieza que lo hace posible recibe el nombre de marketplace de plugins.

Marketplace, plugin y assets

Vamos a fijar el vocabulario en este apartado para entendernos bien. Un marketplace es un catálogo, es decir, un repositorio Git con un manifiesto que declara qué plugins publica y dónde está cada uno. Un plugin es la unidad de distribución, un directorio versionado que empaqueta una capacidad concreta. Los assets son lo que el plugin lleva dentro y lo que cambia el comportamiento del asistente (skills, agentes, comandos, hooks y servidores MCP o LSP).

Un plugin evoluciona igual que una app en la tienda de aplicaciones de tu teléfono móvil. El marketplace sirve siempre la versión publicada y el cliente IA, CLI o IDE la actualiza cuando el usuario o la política de la empresa lo permiten. Si esa versión sale con un fallo, para volver atrás hay que publicar otra, igual que ocurre con una app. Para el gobierno significa que la versión que llega a los equipos la decide quien publica en el catálogo.

Marketplace de plugins: un mismo catálogo para distintos asistentes

Una vez fijado el vocabulario empezamos por el catálogo. En el apartado de contexto hemos hablado de organizaciones que ya han desplegado GitHub Copilot o Claude con licencias corporativas. Son los dos asistentes más habituales que encontramos en los equipos con los que trabajamos (y también a nivel interno) y los dos admiten plugins distribuidos a través de un marketplace. Por eso el resto del artículo se centra en ellos y en los sitios desde donde se usan, que son los que llamaremos clientes (Copilot CLI, Copilot en VS Code y Claude Code).

El mismo fichero de catálogo sirve a todos los clientes a la vez. Anthropic definió su formato para Claude Code y GitHub lo adoptó después en Copilot, por lo que una organización puede publicar un único catálogo corporativo sin mantener uno por asistente si así lo desea.

Conviene comentar (y revisar con el paso del tiempo) que con los plugins la situación está cambiando. En agosto de 2026 se publicó Agent Plugins 1.0, una especificación abierta que mantienen Amazon, Cursor, Microsoft, OpenAI y Vercel (GitHub anunció además la entrada de Google) y en cuyo comité no está Anthropic. GitHub la soporta desde agosto en VS Code, en Copilot CLI y en la app de Copilot, mientras que Claude Code de momento sigue con su formato de siempre.

Aun así, los dos pueden convivir en un mismo plugin. Las skills (el conocimiento de dominio) son lo que más valor tiene de un plugin y los dos asistentes las leen de la misma forma. Los servidores MCP (las integraciones con otros sistemas) también son los mismos para los dos aunque cada uno los declara en su propio fichero. Lo que sí varía es la forma de invocar ese conocimiento a través de agentes, comandos y hooks, que cada asistente define a su manera y espera en sus propias carpetas. En la práctica un mismo plugin lleva una parte común para los dos y una parte específica para cada uno. En el segundo artículo de la serie veremos en detalle qué significa todo eso.

Un ejemplo de repositorio que aloja un marketplace válido y un plugin en su catálogo compatible con los dos asistentes sería el siguiente:

qualtio-plugins-marketplace/
├── .claude-plugin/
│   └── marketplace.json                 # catálogo común
└── plugins/
    └── qualtio-api-test-generator/
        ├── plugin.json                  # manifiesto de Copilot
        ├── .claude-plugin/
        │   └── plugin.json              # manifiesto de Claude
        ├── skills/
        │   └── api-test-generation/     # directorio común
        │       ├── SKILL.md
        │       ├── references/
        │       └── assets/
        ├── com.github.copilot/          # solo Copilot
        │   ├── agents/qualtio-api-test-generator.agent.md
        │   └── commands/generate-api-test.prompt.md
        └── claude/                      # solo Claude
            ├── agents/qualtio-api-test-generator.md
            └── commands/generate-api-test.md

El catálogo/manifiesto de un marketplace (fichero marketplace.json) es simple:

{
  "name": "qualtio-plugins-marketplace",
  "owner": { "name": "qualtio", "url": "https://qualt.io" },
  "plugins": [
    {
      "name": "qualtio-api-test-generator",
      "description": "Genera tests de API REST de integración y de contrato.",
      "version": "1.0.0",
      "source": "./plugins/qualtio-api-test-generator"
    }
  ]
}

A pesar de ser una especificación a priori simple, los campos pueden tomar valores de distintos tipos que permiten diseñar un modelo de gobernanza avanzado. El campo source, por ejemplo, admite en los dos clientes rutas relativas dentro del propio repositorio u otros repositorios de Git (GitHub, Bitbucket o GitLab), lo que permite publicar un catálogo cuyos plugins viven en repositorios distintos con permisos y owners diferentes. Copilot y Claude permiten fijar una rama, una etiqueta o un commit concreto y dar a quien publica el control de qué versión llega a cada equipo. Claude Code admite además paquetes npm, archivos zip por HTTPS y la salida de un comando.

Si el catálogo debe servir a los dos clientes, lo prudente es quedarse en las fuentes comunes pero es perfectamente viable tener dos catálogos paralelos en el mismo marketplace para que cada asistente lo lea y reciba su listado de plugins compatibles. Esto puede resultar útil si tenemos plugins disponibles solo para uno de los asistentes.

Los beneficios son muy claros en cuanto a alojamiento, versionado y distribución de los plugins. La instalación es un comando y la actualización es controlada dado que el usuario recibe una versión nueva solo cuando el mantenedor la publica en la rama o etiqueta a la que apunta el catálogo. En Claude Code, además, el cliente guarda una copia por versión (caché de plugins) así que un cambio publicado sin subir la versión no le llega a nadie.

De esta manera el catálogo queda centralizado como un repositorio Git con historial, política de permisos, ramas, revisiones, modelo de contribución… y estrategia de pruebas también, ¿por qué no? Es un proyecto de código que se puede integrar en los ciclos de desarrollo de la compañía como un producto más.

Plugins: qué llevan dentro y cómo hacerlos compatibles con cada asistente

Una vez visto el catálogo en este apartado vamos a ver qué assets contiene cada plugin. Un plugin puede ser tan pequeño como una skill o tan completo como un paquete con agentes, comandos, hooks y servidores MCP. La primera pieza que tienen en común todos los plugins es su fichero plugin.json que proporciona los datos básicos del plugin y permite también mapear los directorios de sus assets si se desea establecer una estructura personalizada.

Por ejemplo, para Claude:

{
  "name": "qualtio-api-test-generator",
  "description": "Genera tests de API REST de integración y de contrato.",
  "version": "1.0.0",
  "author": { "name": "qualtio", "url": "https://qualt.io" },
  "commands": "./claude/commands/",
  "agents": "./claude/agents/qualtio-api-test-generator.md"
}

Los primeros campos son los datos del plugin y los dos últimos indican dónde están sus comandos y sus agentes. Claude los busca por defecto en las carpetas commands/ y agents/ de la raíz del plugin, pero su manifiesto permite llevarlos a otra carpeta con esos dos campos. Nosotros los llevamos a claude/ para dejar un diseño más limpio separado por asistente. Skills y conexiones a MCPs van por defecto a la raíz en skills/ y fichero .mcp.json.

El manifiesto de Copilot para el mismo plugin sigue la especificación Agent Plugins (ojo al campo $schema) y es todavía más corto debido a que la especificación no admite rutas custom:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "qualtio-api-test-generator",
  "version": "1.0.0",
  "description": "Genera tests de API REST de integración y de contrato.",
  "author": { "name": "qualtio", "url": "https://qualt.io" }
}

En este manifiesto basado en el schema Agent Plugins, Copilot no permite fijar dónde va cada pieza y las skills van a skills/, el MCP en mcp.json y lo propio de Copilot dentro de com.github.copilot/.

A continuación listamos los assets principales que un plugin puede contener:

Cada asistente añade además piezas propias que cambian la configuración o el comportamiento del asistente sin ser la habilidad en sí. Copilot también admite reglas (rules) y en Claude la lista es más larga (estilos de salida, workflows y, en experimental, temas y monitores).

Cuando el plugin crece

Los dos ecosistemas divergen principalmente cuando se necesitan puntos de entrada (métodos de invocación) nativos en cada asistente o cliente. Copilot espera sus agentes y comandos (prompts) dentro de com.github.copilot/ con sus propias extensiones de fichero, mientras que Claude los espera en sus carpetas por defecto o en las que indique su manifiesto, como hemos visto. El contenido de cada fichero (campos obligatorios, opcionales, tipos de valores…) también varía en función del proveedor. Las skills, afortunadamente, las leen los dos igual y no plantean este problema.

A partir de este punto la validación empieza a tomar peso. Cada cambio funcional puede obligar a tocar piezas core del plugin que cada asistente puede interpretar de forma distinta y alterar el resultado final.

Plugins: estrategia de validación

Hasta ahora hemos visto cómo se monta el catálogo y qué puede contener cada plugin. La mayoría de iniciativas se quedan aquí, montando el marketplace, publicando dos o tres plugins y dando por hecho el trabajo. Un marketplace corporativo es un producto software con usuarios internos y merece el mismo trato que cualquier otro.

Un marketplace corporativo es un producto software con usuarios internos.

El significado de "probar" un plugin no es evidente, por lo que nosotros lo hemos acabado organizando en tres niveles de validación con costes y frecuencias muy distintas:

Nivel 1: que el plugin cargue

El primer nivel es gratis, muy rápido y se debe ejecutar siempre. Comprueba que el plugin carga, es decir, que manifiestos, rutas y nombres son correctos y que la versión de Copilot y la de Claude siguen siendo compatibles. Claude Code trae un validador nativo de serie pero Copilot no tiene equivalente por lo que toda la validación del lado Copilot hay que escribirla y esto es clave ya que representa la mitad de la superficie de un plugin multicliente.

La segunda comprobación de este nivel es la paridad de puntos de entrada. Como hemos visto, cada asistente tiene su propio agente y su propio comando para el mismo plugin. Es fácil que alguien corrija una regla en el agente de Copilot y se olvide del de Claude. Nuestro script comprueba que las instrucciones del agente son idénticas en los dos asistentes, que los comandos se limitan a lanzar su agente sin añadir reglas propias y que cada herramienta que se concede en Copilot tiene su equivalente en Claude. Todas estas validaciones están ancladas a un hook de pre-commit.

Nivel 2: que el plugin funcione

Es difícil encontrar ejemplos o herramientas para abordar este punto porque las herramientas disponibles están muy desequilibradas entre clientes. Anthropic tiene una herramienta oficial para evaluar un plugin (claude plugin eval) pero solo cubre el runtime de Claude, sin que en el lado de Copilot exista nada equivalente ni para validar ni para evaluar. Como nuestros clientes utilizan los dos ecosistemas hemos montado un evaluador que usa un formato de casos basado en el de la herramienta de Anthropic y los ejecuta en los dos clientes.

Para este artículo interesa una anécdota que representa un caso típico. En Copilot la skill se activaba y el plugin cumplía su contrato en todos los casos. En Claude Code, con el mismo plugin y el mismo prompt, la skill estaba cargada pero el modelo no la invocaba. Resolvía la tarea de memoria y devolvía prosa libre en lugar de la estructura de informe obligatoria. La causa estaba en la redacción de la descripción de la skill y se arregló reescribiéndola. Con un evaluador de un solo cliente aquel informe habría salido en verde. Si un plugin se distribuye a dos clientes, se debe evaluar en los dos.

Si un plugin se distribuye a dos clientes, se debe evaluar en los dos.

Nivel 3: cuánto contexto consume

Este último nivel tampoco se suele mirar mucho en el día a día. Los nombres y las descripciones de las skills, agentes y comandos de un plugin entran en el contexto de cada sesión aunque no se usen. Un plugin que se activa perfectamente pero se come miles de tokens de cada conversación es un plugin caro cuyo coste paga cada desarrollador en cada sesión. Claude trae comandos nativos y gratuitos para verlo y el evaluador del nivel anterior lo mide comparando con y sin plugin para evitar que el catálogo engorde sin que nadie lo note. De momento solo lo medimos en Claude, aunque ya estamos adaptando el evaluador para leer el consumo de tokens que reporta Copilot y tener la misma medida en los dos asistentes en su próxima versión.

Estos tres niveles pueden y deben ejecutarse en local en primera instancia como cualquier tipo de test. El primer nivel puede incorporarse en el hook de pre-commit con sus dos validaciones, el segundo lanzarse antes de cambiar una regla y en cada release y el tercero en cada release y de forma periódica. Es perfectamente viable llevar estas validaciones a un sistema de CI como Jenkins o GitHub Actions ejecutando los asistentes sin interfaz vía API o con una licencia dedicada. Algo que daría para otro artículo más.

Gobierno y seguridad: control sobre nuestro catálogo de plugins

Después de la ingeniería viene lo que decide que el departamento de seguridad diga que sí.

Como hemos visto, un plugin puede incorporar assets que no cumplan del todo la política de seguridad de una organización. Por eso los dos ecosistemas han publicado controles administrativos de grano fino.

Un marketplace permite montar un modelo de gobierno base y las herramientas de Copilot y de Claude permiten administrar desde la organización qué marketplaces y qué plugins se usan con las licencias corporativas y qué puede hacer cada plugin.

En las grandes organizaciones los ordenadores suelen estar plataformados. Se entregan con una imagen corporativa y se gestionan de forma centralizada con herramientas de gestión de dispositivos (MDM) como Intune, Jamf o las directivas de grupo de Windows. Los dos asistentes leen su política de esos mismos canales, por lo que la configuración de IA puede viajar junto al antivirus, la VPN o los certificados sin que el desarrollador tenga que hacer nada ni pueda sobrescribirla. Para los equipos que no están plataformados, los dos admiten también una política que se descarga de la cuenta corporativa con la que el usuario inicia sesión.

En Claude Code la política se despliega como perfil de configuración en macOS, como clave de registro en Windows, como fichero managed-settings.json en una carpeta del sistema o desde la consola de administración de claude.ai. Con strictKnownMarketplaces se define la lista blanca de marketplaces permitidos, con extraKnownMarketplaces se registra el catálogo corporativo sin que el usuario haga nada y con enabledPlugins se decide qué plugins llegan activados. En los planes Team y Enterprise el panel de administración de claude.ai gobierna además Claude Desktop y el chat web. Desde ahí se sincroniza el marketplace corporativo y se decide para cada plugin si queda oculto, disponible, instalado por defecto u obligatorio.

GitHub Copilot ofrece lo mismo para Copilot CLI y VS Code desde julio de 2026 utilizando las mismas vías (registro de Windows, preferencias gestionadas de macOS o un fichero managed-settings.json en una carpeta del sistema, como /etc/github-copilot/ en Linux) o con un managed-settings.json en el repositorio .github-private de la organización.

VS Code suma sus propias directivas de empresa, que se distribuyen con plantillas ADMX: ChatStrictMarketplaces limita la confianza a los marketplaces definidos por política, ChatEnabledPlugins es la lista blanca de plugins y ChatPluginsEnabled permite apagarlos por completo. Alrededor hay un cinturón que limita lo que un plugin puede llegar a hacer, con políticas para permitir solo los hooks de plugins gestionados por la organización (ChatAllowManagedHooksOnly), restringir los servidores MCP (ChatAllowedMcpServers) o aislar los comandos que ejecuta el agente (ChatAgentSandboxEnabled). El resto de claves relevantes está en la documentación oficial de cada proveedor pero con las descritas ya nos podemos hacer una idea de que estas políticas existen y son operativas. En cualquier caso las repasaremos en el siguiente artículo.

Estudiando las diferentes opciones y combinaciones que proporciona cada herramienta y sus canales para aplicarlas podemos también concluir que no hace falta elegir entre control y autonomía. Se puede permitir el marketplace corporativo y los públicos a la vez, exigir revisión para lo interno y aprovechar cada nueva política de control a nivel empresarial que Anthropic y GitHub ponen a disposición de sus clientes desde el día en que la liberan. También se puede cerrar todo salvo una lista blanca en los equipos que tratan datos sensibles y abrir la mano en el resto. Son decisiones de política que pueden conseguir un buen control inventariado sin matar la creatividad de los equipos ni penalizar su rendimiento.

No hace falta elegir entre control y autonomía.

Verlo funcionando

Para ver todo lo anterior funcionando hemos publicado un marketplace de ejemplo con dos plugins. El primero es mínimo (una sola skill) y el segundo es un plugin más completo que funciona en los dos asistentes. El marketplace se registra una vez y a partir de ahí instalar o actualizar un plugin es un comando (si es vía CLI) o actualizar una extensión (si es vía IDE).

# registrar el marketplace (una sola vez)
claude plugin marketplace add qualtio/qualtio-plugins-marketplace
# instalar un plugin del catálogo
claude plugin install qualtio-api-test-generator@qualtio-plugins-marketplace
# traer la última versión publicada
claude plugin marketplace update qualtio-plugins-marketplace
claude plugin update qualtio-api-test-generator@qualtio-plugins-marketplace

copilot plugin marketplace add https://github.com/qualtio/qualtio-plugins-marketplace.git
copilot plugin install qualtio-api-test-generator@qualtio-plugins-marketplace
copilot plugin marketplace update qualtio-plugins-marketplace
copilot plugin update qualtio-api-test-generator

Conclusiones

El shadow AI en las herramientas de desarrollo se reduce haciendo que el camino gobernado sea también el camino cómodo. Un marketplace de plugins aplica esa misma idea al tooling de IA y, aunque no lo esperábamos al empezar, un mismo catálogo sirve a Copilot y a Claude Code. Esto sitúa a los marketplaces como una base muy sólida para un modelo de gobernanza sobre IA corporativa y abre un abanico de posibilidades muy interesante a partir de ella.

Hacer que el camino gobernado sea también el camino cómodo.

A medida que hemos ido incorporando este sistema hemos visto que, debido a la capacidad de entrega de nuevas features de GitHub Copilot y Claude, nos hemos quedado "desactualizados" en cuestión de pocos días o semanas en cuanto a estructura de plugins, assets disponibles o nuevas funcionalidades que aportan más control a la gobernanza. A pesar de ello consideramos que es más valioso intentar seguir el ritmo a los proveedores e incorporar las nuevas características de cada release en lugar de intentar crear desarrollos o mecanismos propios a mantener por la propia compañía. Eso genera silos y nos hace competir contra ellos intentando copiar sus novedades, no adaptándonos a ellas y aprovechándolas según salen.

En nuestra experiencia, la acogida de los equipos a la fórmula de marketplaces ha sido muy positiva. El hecho de poder centralizar un marketplace para la compañía y además poder tener marketplaces a nivel interno del equipo supone una solución estable y muy limpia. Todos los equipos (incluido el nuestro) tenían casos de copy/paste de skills, agentes, symlinks, hooks, instructions o demás apaños configurados en los distintos asistentes y además nunca se llegaba a saber cuál de esos assets era la última versión o si funcionaba mejor que el que alguien se había puesto en su portátil viejo.

Esos ficheros se van moviendo por Teams o Slack sin control alguno pero ya hace muchos años que no enviamos código de las aplicaciones por mensajería (o disquetes), sino que lo guardamos en repositorios de código.

Como hemos visto, todavía queda mucho camino por delante en la estructura de los plugins, en su validación y en las políticas que cada proveedor va publicando. Esperamos que este artículo haya servido para ver que el tooling de IA se puede gobernar como cualquier otro software sin frenar a los equipos. En el segundo artículo de la serie veremos cómo construir un plugin que funcione en varios asistentes y en el tercero cómo validar que un cambio no rompe nada antes de publicarlo.

¡Nos vemos en los siguientes!

Referencias