El inventario de IA de tu empresa triplica tu lista de modelos

La tesis cabe en una multiplicación: sea cual sea la lista de modelos que tu empresa cree estar usando, su superficie real de IA es unas tres veces mayor. Lo publicó Help Net Security el 5 de agosto en este análisis sobre el footprint de IA en la empresa, y la proporción encaja con lo que encontramos cada vez que auditamos un entorno.

El motivo no es que haya modelos escondidos en un armario. Es que casi nadie cuenta lo que rodea al modelo, y ahí vive el riesgo real.

Lo que se queda fuera del inventario

SaaS con IA activada por defecto: el CRM, el ATS, la suite ofimática y la herramienta de soporte incorporaron asistentes en actualizaciones que nadie leyó.
Servidores MCP: cada uno es una vía de acceso a datos que corre con los permisos del usuario que lo lanzó, no con los de una cuenta de servicio auditada.
Asistentes dentro del IDE y extensiones de navegador, instalados por decisión individual, con acceso a repositorios y sesiones ya autenticadas.
Claves de API repartidas entre variables de entorno, ficheros de configuración locales y algún .env que acabó dentro de un backup.
Agentes internos que alguien montó para una tarea concreta, que siguen ejecutándose y que nadie ha vuelto a revisar.

Ninguno de esos elementos aparece cuando alguien responde a la pregunta de qué modelos usamos. Todos aparecen cuando la pregunta es por dónde pueden salir nuestros datos.

La distinción importa porque los controles se aplican a las conexiones, no a los modelos. Bloquear un proveedor no sirve de nada si la misma capacidad entra por una extensión de navegador o por una función que el fabricante del CRM activó en su última versión.

El inventario que sí sirve

Contar modelos es contar proveedores. El inventario útil se hace por conexiones y es un ejercicio bastante mecánico:

Localizar ficheros de configuración MCP en equipos y repositorios: claude_desktop_config.json y .mcp.json son un buen punto de partida.
Listar los hooks configurados en Claude Code. Son comandos shell que se ejecutan solos ante eventos del ciclo de vida, así que son código con permisos, no configuración inocua.
Revisar qué integraciones OAuth han autorizado los usuarios contra herramientas de IA, desde la consola de Google Workspace o Microsoft 365.
Pedir a cada proveedor SaaS la lista de funciones de IA activas en tu tenant y en qué región se procesan los datos.
Cruzar el gasto: las facturas de API delatan proyectos que no figuran en ningún inventario.

Por qué importa ahora

Porque tanto el marco regulatorio europeo como los esquemas de certificación que están adoptando las empresas parten del mismo requisito aburrido: saber qué sistemas de IA usas, para qué y con qué datos. Sin inventario no hay evaluación de riesgo, y sin evaluación de riesgo la documentación de cumplimiento es literatura.

Hay un segundo motivo, menos formal. El coste de un incidente con un agente no se parece al de una filtración clásica, porque el agente no solo lee: actúa. Un servidor MCP con permisos de escritura sobre un sistema de producción es, a efectos prácticos, un usuario más con acceso permanente, sin caducidad de contraseña y sin nadie mirando su actividad.

Para quién es útil

Para responsables de seguridad que necesitan una cifra con la que abrir la conversación en un comité. Para equipos de IT pequeños, que suelen descubrir la mitad de estas conexiones el día que falla una. Y para cualquiera que esté a punto de firmar una política de uso de IA: escribir normas sobre un mapa incompleto genera cumplimiento aparente, que es peor que no tener política.

En las integraciones que montamos, el número de conexiones siempre sorprende más que el número de modelos: un puñado de proveedores y decenas de puntos de contacto es un reparto habitual. Si solo hay margen para una cosa este trimestre, conviene hacer el recuento antes que la norma.