«Tenemos una política de IA». ¿Dónde está el inventario?

Imagine la próxima reunión de gobernanza.

Alguien pregunta qué sistemas de IA utiliza la organización. La política llega de inmediato. Tiene número de versión, fecha de aprobación y firma del director.

El inventario tarda más.

TI envía una lista de productos aprobados. Marketing añade el asistente que utilizan mediante cuentas personales. Ventas menciona el bot que se incorpora a las llamadas con clientes. RRHH dice que la plataforma de selección de personal tiene «algunas funciones de IA», pero nadie sabe con exactitud cuáles están habilitadas.

Entonces alguien pregunta qué hacen los empleados con las herramientas aprobadas.

Segundo silencio.

Todos asumían que otra persona llevaba el control. Nadie mintió necesariamente. Respondieron preguntas distintas: qué estaba aprobado, qué se había adquirido, qué se recordaba.

Ninguna de esas respuestas equivale exactamente a qué se usa. Y saber qué se usa tampoco establece si se usa correctamente.

El inventario de IA debe describir la organización que se tiene, no la organización que la política supone que se tiene.

Una lista de proveedores no es un inventario de IA

El nombre de un proveedor indica a quién enviar la factura. No indica qué hacen los empleados, qué información entra en el sistema ni las decisiones de quién influyen en sus resultados.

Considere un asistente usado para reescribir contenidos de marketing público. Ahora considere el mismo producto utilizado para evaluar candidatos a un puesto de trabajo. El proveedor no ha cambiado. El propósito, la información y las personas afectadas, sí.

Mi recomendación es mantener un registro por sistema o despliegue y vincular bajo él los casos de uso materialmente distintos. Se crea una entrada de caso de uso independiente cuando el propósito, los datos, los permisos o las consecuencias cambian lo suficiente como para requerir una evaluación diferente.

No se necesita una fila por cada prompt. Sí es necesario distinguir «redacta contenido público» de «apoya decisiones de selección de personal».

Una fila por proveedor oculta las diferencias. Una fila por prompt genera una carga administrativa inasumible.

El inventario no es un accesorio de gobernanza improvisado. El Playbook del AI Risk Management Framework de NIST aborda explícitamente los inventarios de sistemas de IA en GOVERN 1.6, incluidos su alcance, los atributos registrados y las responsabilidades de mantenimiento. (NIST AI Resource Center)

La pregunta práctica es si el suyo puede responder a una pregunta de seguimiento.

La IA que nadie compró también cuenta

Comience por la shadow AI: herramientas o despliegues utilizados para el trabajo sin visibilidad organizativa ni autorización suficiente.

Defina el alcance del descubrimiento más allá de los productos adquiridos de forma independiente. Pregunte sobre cuentas personales, extensiones del navegador, asistentes de reuniones, funciones de IA dentro de software existente, modelos desarrollados internamente y flujos de trabajo que llaman a APIs de modelos externos.

Pregunte también a los proveedores. ¿Utiliza un proveedor de servicios IA para tratar su información como parte del trabajo externalizado?

No limite el ejercicio a la IA generativa. Incluya sistemas de pronóstico, clasificación, reconocimiento de imágenes y recomendación basados en IA donde se utilicen. Una ventana de chat no es un requisito de entrada.

Mantenga visibles los descubrimientos inciertos. «Funcionalidad de IA por verificar» es un estado temporal aceptable. Excluir algo en silencio porque nadie lo entiende no es un método de descubrimiento.

Del mismo modo, registre los usos retirados o bloqueados como retirados o bloqueados. No borre su existencia simplemente porque ya no encajan en el panorama aprobado.

Encontrar esos sistemas es necesario. No es todo el trabajo.

La herramienta está aprobada. El uso, no.

Elimine ahora las cuentas personales del escenario.

Imagine que todos utilizan la plataforma corporativa aprobada. Compras verificó el contrato. Seguridad revisó el despliegue. El equipo de privacidad evaluó el tratamiento propuesto. El acceso está gestionado. El sistema tiene un responsable.

Entonces alguien lo utiliza para algo que ninguna de esas revisiones contemplaba.

Eso es shady AI: una herramienta aprobada usada de forma no gobernada o inadecuada.

Utilizo esta distinción para separar dos problemas que vale la pena investigar: las herramientas de las que no se ha dado cuenta adecuadamente, y los usos que escapan a la gobernanza dentro del entorno aprobado. Son etiquetas de trabajo, no un juicio sobre la intención de los empleados.

Considere tres ejemplos ficticios.

Un asistente está autorizado para redactar comunicaciones internas generales. Un mánager sube notas de evaluación identificables de empleados y le pide que recomiende a quién ascender. El producto está aprobado. Ese propósito y esas entradas no formaban parte de la aprobación.

Un asistente de reuniones está autorizado para reuniones de proyecto ordinarias. Alguien lo incorpora a una discusión confidencial sobre una queja de un empleado, pese a una exclusión explícita. Mismo proveedor, misma cuenta, límite diferente.

O un asistente de atención al cliente está aprobado para redactar respuestas, siempre que un agente las verifique antes de enviarlas. El equipo sigue usándolo para la atención al cliente. Nadie añade un conector ni cambia el modelo. Simplemente empiezan a enviar los borradores sin las comprobaciones requeridas.

La shady AI no es solo un nuevo caso de uso que nadie evaluó. También es un caso de uso aprobado al que se le han retirado silenciosamente sus salvaguardas.

El Playbook de NIST aborda explícitamente el uso indebido de sistemas y la necesidad de definir el alcance de la aplicación y las responsabilidades humanas. Comprobar el nombre de un producto en una lista aprobada no resuelve esas preguntas. (NIST AI Resource Center)

La aprobación necesita un límite

«Aprobado» necesita una segunda frase.

¿Aprobado para qué tareas? ¿Con qué información? ¿Para qué usuarios y destinatarios? ¿Con qué autoridad para actuar? ¿Sujeto a qué controles?

Sin esos límites, ¿qué se pide exactamente que cumplan los empleados?

Investigue si las condiciones fueron comunicadas, si el flujo de trabajo las hace viables y si alguien verifica que se cumplen. No asuma que toda desviación es malintencionada. Tampoco asuma que la ausencia de intención maliciosa hace que la desviación sea inofensiva.

La lista de herramientas aprobadas indica qué pueden abrir los empleados. No indica qué pueden hacer una vez que está abierto.

Empiece por el trabajo. Después revise los registros.

«¿Usas IA?» no es la pregunta con la que yo empezaría.

Yo preguntaría:

«Muéstrame cómo redactas, resumes, traduces, programas, clasificas o emites recomendaciones ahora. ¿Qué te ayuda a hacer ese trabajo?»

Después pregunte qué se sube, pega, conecta o genera por el camino.

Realice esas conversaciones con quienes hacen el trabajo, no solo con los responsables de departamento. Pregunte también sobre experimentos y cuentas gratuitas, además de los despliegues oficiales. Use demostraciones anonimizadas; el descubrimiento no requiere copiar registros de clientes en sus notas.

Para las herramientas aprobadas, añada otra pregunta:

«¿Qué ocurre con el resultado y qué comprobaciones se realizan antes de que alguien actúe en consecuencia?»

Ahí es donde comienza la investigación de shady AI. Un producto puede estar presente en todos los registros de compras y aun así utilizarse fuera de sus límites autorizados.

A continuación, contraste las respuestas con evidencias.

Revise compras, gastos, contratos y cuestionarios a proveedores. Dentro de su visibilidad autorizada, examine inventarios de aplicaciones, integraciones de identidad, configuraciones de administración SaaS, extensiones, endpoints de modelos y registros de desarrollo interno.

Investigue las discrepancias. Una herramienta declarada sin compra correspondiente no es automáticamente una respuesta incorrecta. Una integración que nadie mencionó necesita un responsable. Una funcionalidad habilitada requiere una conversación sobre si se usa y cómo.

Una conexión a un servicio no explica por sí sola el propósito de negocio ni establece qué información se envió. Registre qué verificó, cuándo, qué reveló y qué sigue siendo incierto.

Explique el ejercicio a los empleados. Fomente la divulgación sin prometer inmunidad general por uso indebido. Acuerde un enfoque de monitorización proporcionado con los equipos de privacidad y legal pertinentes, incluida la consulta necesaria con los empleados.

Limite la recopilación, controle el acceso y defina la retención. El principio de minimización de datos del GDPR se aplica también a los datos personales recogidos durante el descubrimiento. (EUR-Lex)

No resuelva la shadow AI creando vigilancia encubierta.

Construya un registro que sobreviva a una pregunta de seguimiento

Esta es la estructura de trabajo que yo utilizaría. Trátela como un punto de partida operativo, no como una afirmación de que cada marco prescribe exactamente estas columnas.

Mantenga distinguibles el uso previsto, el uso autorizado y la práctica observada. De lo contrario, la entrada se convertirá silenciosamente en otra copia de la política.

No añada una columna vaga de «Shady AI: sí/no» y considere el asunto resuelto. Registre el límite, la observación y la diferencia.

Un ejemplo, tres respuestas distintas

Tome un despliegue ficticio: AI-017, un asistente de redacción para atención al cliente.

Maya, responsable de Soporte, es la propietaria del caso de uso. El asistente utiliza tickets de clientes y una base de conocimiento controlada para producir borradores de respuesta. Su integración puede guardar borradores, pero no enviarlos.

El flujo de trabajo autorizado exige que un agente de soporte verifique la exactitud y la idoneidad antes de enviar.

Durante una revisión ficticia del flujo de trabajo, el agente genera una respuesta y la envía sin comprobar el contenido. La revisión requerida se ha convertido en un clic.

La plataforma está aprobada. El caso de uso está autorizado. La condición de uso no se está cumpliendo.

Son tres respuestas distintas. Una celda verde de «Aprobado» no puede representarlas.

Registre la observación, investigue la causa y asigne una acción correctiva. Después verifique que el paso de revisión funciona en la práctica, en lugar de emitir simplemente otro recordatorio.

Mantenga igualmente explícita la información faltante. «Retención desconocida; asignada al responsable del proveedor; respuesta prevista el viernes» es accionable.

«Retención: conforme» no es una respuesta a menos que alguien pueda demostrar qué significa y cómo se estableció.

Tome prestado del célebre SBOM. Construya un AI-BoM.

El software bill of materials, o SBOM, parte de una idea útil: el nombre del producto no indica lo que el producto contiene. Registra los componentes de software y sus relaciones en la cadena de suministro. (NIST)

Un AI bill of materials, o AI-BoM, extiende ese trabajo de composición a los elementos específicos de la IA. CycloneDX admite información sobre modelos, conjuntos de datos, configuraciones y dependencias. La documentación de IA de SPDX también describe relaciones que involucran modelos, datos, prompts y agentes. (CycloneDX)

Esto no es su hoja de cálculo de herramientas aprobadas con un nombre de archivo más impresionante.

Mantenga diferenciados tres entregables:

El inventario registra qué utiliza la organización, con qué propósito y bajo la responsabilidad de quién.

El AI-BoM registra de qué está compuesto un sistema concreto y de qué depende.

El registro de riesgos registra qué podría salir mal y qué está haciendo la organización al respecto.

Vincúlelos. No los convierta en tres versiones competidoras de la realidad.

Comience con un límite definido

Para este ejercicio, comience con un sistema desplegado específico. Asigne al registro de composición un identificador, revisión, entorno, fecha y responsable de mantenimiento. Vincule los SBOMs de software existentes y la documentación a nivel de modelo donde estén disponibles.

Sea explícito sobre si el registro describe el despliegue completo, un modelo o el servicio de un proveedor.

El documento de un modelo del proveedor no describe la integración de tickets, el servicio de recuperación y los permisos que sus ingenieros añadieron alrededor de él.

Para una primera versión práctica, yo capturaría o referenciaría los siguientes grupos:

Estos grupos reflejan las relaciones de composición más amplias descritas por CycloneDX y SPDX. Adáptelos al formato que utilice; conserve los detalles de soporte en registros vinculados donde el formato elegido no los capture directamente. (CycloneDX)

Registre las relaciones, no solo los ingredientes

Para AI-017, conecte la integración de tickets, el servicio de recuperación de la base de conocimiento, el modelo de generación alojado, la plantilla de prompt controlada y la integración de redacción de borradores.

¿Qué componente lee el ticket? ¿Qué fuente se consulta? ¿Qué modelo recibe la información ensamblada? ¿Qué componente escribe el borrador?

Mantenga los datos de entrenamiento separados de la información recuperada o suministrada durante el uso. «Datos» no es una relación suficientemente precisa.

Imagine ahora un cambio de modelo o una biblioteca vulnerable en el servicio de recuperación. Los registros vinculados deben ayudar a identificar el despliegue afectado y su responsable sin necesidad de reiniciar el descubrimiento.

Reúna evidencias a partir de configuraciones de despliegue, manifiestos de dependencias, registros de modelos y documentación del proveedor. Distinga los hechos verificados internamente de las declaraciones del proveedor.

Cuando un proveedor no divulga la versión exacta del modelo o los conjuntos de datos subyacentes, registre la limitación. Capture el identificador de servicio disponible, la fecha de documentación y los acuerdos de notificación de cambios. No fabrique precisión.

Comience con una tabla controlada cuando sea necesario y avance hacia un formato legible por máquina compatible con sus herramientas. No asuma que una hoja de cálculo se vuelve interoperable simplemente porque su nombre de archivo contiene «BOM».

Mantenga fuera de él las credenciales, la información bruta de clientes y el contenido confidencial de conjuntos de datos. Referencie en su lugar los registros controlados.

Los ingredientes pueden permanecer igual mientras el uso falla

Vuelva a AI-017.

El modelo, la aplicación y las integraciones no cambian. El equipo simplemente deja de revisar los borradores.

El AI-BoM no ha cambiado necesariamente. La práctica operativa, sí.

Vincule el registro de composición a los casos de uso autorizados, sus condiciones y las evidencias de operación real. Actualice el AI-BoM cuando cambien los componentes o configuraciones registrados. Reevalúe el uso cuando cambien su propósito, información, destinatarios o salvaguardas, incluso cuando el software no cambie.

Un AI-BoM completo no puede indicarle si alguien leyó realmente la respuesta antes de enviarla.

«¿Entrena con nuestros datos?» no es toda la evaluación de privacidad

Haga la pregunta sobre el entrenamiento. Después continúe.

Un compromiso de no entrenamiento no responde si la información se retiene para la prestación del servicio, se almacena en historiales de conversación, es accesible para el personal de soporte o se transfiere a otro servicio. Trátelas como preguntas separadas que requieren evidencias.

Para cada caso de uso, investigue los prompts, los archivos adjuntos y las fuentes conectadas. Siga los resultados y los registros. Establezca quién recibe la información y cuáles son los acuerdos de eliminación verificados.

Para los asistentes con capacidad de actuar, investigue también la autoridad, no solo la información. ¿Puede el sistema leer un buzón completo, actualizar un registro de cliente o enviar material fuera de la organización?

El análisis de CNIL sobre la IA agéntica destaca las complicaciones que generan las fuentes de datos conectadas, la memoria persistente, el movimiento entre servicios y las acciones delegadas. Lleve a la función de privacidad una descripción de esas operaciones, no solo la página de seguridad del proveedor. (CNIL)

Aquí es también donde importa la shady AI. Una evaluación de la redacción de comunicaciones internas generales no describe el uso de registros de evaluación de empleados para recomendar ascensos.

Identifique el propósito de tratamiento real, las partes relevantes, la base jurídica aplicable, las disposiciones de transparencia y cualquier transferencia internacional. Vincule el inventario a los registros de tratamiento y evaluaciones de privacidad correspondientes. (EUR-Lex)

El inventario y el AI-BoM no satisfacen automáticamente esos requisitos. El artículo 30 del GDPR aborda los registros de actividades de tratamiento; el artículo 35 exige una DPIA cuando el tratamiento sea susceptible de generar riesgos elevados para los derechos y libertades de las personas. «IA» en el nombre del producto no constituye, por sí solo, la evaluación. (EUR-Lex)

Proteja también el propio inventario. Un registro que describe fuentes sensibles e integraciones potentes no debería convertirse en un directorio de acceso general de cosas interesantes a las que acceder.

«Descubierto» no significa «aprobado»

Mantenga el estado de descubrimiento separado de la autorización.

«Comunicado por un departamento» y «verificado en la consola de administración» describen evidencias. «En revisión», «autorizado con restricciones», «suspendido» y «retirado» describen decisiones o estados operativos.

Si las condiciones de uso se están cumpliendo realmente requiere otra respuesta.

Un sistema puede estar verificado como presente y seguir siendo inaceptable para su uso actual. Añadirlo al registro no lo legitima.

Derive los descubrimientos hacia la evaluación, con responsables y fechas nominados. Yo priorizaría la investigación cuando el uso implique información sensible, decisiones de consecuencia sobre personas, permisos amplios o dependencias de producción.

Para la shady AI, decida si la respuesta requiere clarificar instrucciones, restaurar una salvaguarda, restringir el acceso, evaluar un nuevo uso o detener la actividad.

Cuando falte información, decida qué puede ocurrir mientras se resuelve la laguna. «En revisión» no debería significar «continuar indefinidamente».

Cuando el descubrimiento sugiera una exposición o un incidente, use el proceso de respuesta existente. Completar la entrada del inventario no es contención. La guía de gobernanza de NIST conecta explícitamente el monitoreo de IA con la respuesta a incidentes y la responsabilidad de abordar los problemas. (NIST AI Resource Center)

Una vez establecidos los hechos, conéctelos con el trabajo de gestión de riesgos existente. Los artículos sobre cómo construir un registro de riesgos de IA e integrar el riesgo de IA en el ISMS cubren ese siguiente paso. (Cyber Academy)

Una celda verde es una decisión que alguien debe poder explicar.

Manténgalo actualizado, o llámelo documento histórico

Asigne un custodio al inventario y responsables de negocio a sus entradas. Los responsables técnicos deben mantener las evidencias de composición y configuración pertinentes. El Playbook de NIST trata la propiedad definida y la revisión continua como actividades de gobernanza, no como tareas opcionales tras la recopilación inicial. (NIST AI Resource Center)

Vincule las actualizaciones a los cambios que ya requieren atención: nuevos casos de uso, funciones habilitadas, cambios de modelo, nuevas fuentes de datos, integraciones adicionales, permisos modificados y retiradas.

Incluya también los cambios operativos. Eliminar un paso de revisión o cambiar quién recibe un resultado puede justificar una reevaluación aunque nadie despliegue código nuevo.

Para AI-017, pasar de «guarda borradores de respuesta» a «envía respuestas automáticamente» requiere una nueva decisión. Descubrir que los agentes ya envían borradores sin revisarlos requiere acción inmediata, no esperar a la próxima versión del software.

Actualice los registros vinculados conjuntamente y conserve las versiones anteriores relevantes. Es necesario establecer qué estaba en uso en el momento de un evento, no solo qué está configurado hoy.

Use las revisiones periódicas para detectar cambios no registrados, no como permiso para ignorar todo lo que ocurre entre revisiones.

Para los informes a la dirección, muestre la propiedad verificada, las evaluaciones vencidas, las lagunas de información sin resolver y las desviaciones de las condiciones aprobadas. Describa el alcance de su trabajo de descubrimiento.

Sea cauteloso con «100% de la IA inventariada». Contar todo lo que ya figura en su lista no establece que no falte nada.

Empiece por el inventario. Después conecte el resto.

Elija un departamento y recorra su trabajo real.

Registre los sistemas y los usos. Verifique los responsables. Trace la información. Compare las condiciones aprobadas con la práctica observada. Construya el AI-BoM para un despliegue significativo y vincúlelo al inventario.

Convierta las preguntas sin respuesta en acciones asignadas.

Eso le da un punto de partida que puede mejorar, no una afirmación de completitud sin respaldo.

La próxima vez que alguien pregunte qué IA utiliza la organización, debe poder mostrar qué encontró, de qué depende, quién es responsable y qué queda por resolver.

También puede adjuntar la política. Simplemente no debería ser su única respuesta.

Para el trabajo de gobernanza más amplio, explore el AI Risk Governance Toolkit. Úselo junto con este enfoque, con los hechos, responsables y decisiones que su organización realmente necesita.

Explorar el AI Risk Governance Toolkit →

Encuentre la IA que nadie declaró. Examine la IA que todos aprobaron. Documente de qué dependen ambas y verifique cómo se usan ambas.