Respuesta directa
En pocas palabras
Un inventario de sistemas de IA registra cada caso de uso como una unidad gobernable: propósito, usuarios, decisiones apoyadas, estado, responsable, versión, modelos, datos, herramientas, integraciones, permisos, personas afectadas, nivel de riesgo, controles, evidencia y fechas de revisión. Debe incluir sistemas comprados, desarrollados, integrados y usos no autorizados descubiertos, y mantenerse conectado con cambios, incidentes y retiro.
El inventario convierte herramientas dispersas en responsabilidad visible
Una organización no puede gobernar una capacidad de IA que no sabe que existe. El inventario reúne los sistemas y usos que generan, recomiendan, clasifican, resumen o ejecutan acciones dentro del trabajo comercial. Permite responder qué está activo, con qué propósito, qué personas y datos intervienen, quién puede decidir sobre el sistema y qué evidencia respalda su operación.
NIST incluye en Govern 1.6 mecanismos para inventariar sistemas de IA y asignar recursos según las prioridades de riesgo. Su Playbook describe el inventario como una base organizada de artefactos que puede apoyar mantenimiento y respuesta a incidentes. Esta guía propone una implementación operativa; no atribuye a NIST una plantilla obligatoria ni una secuencia universal.
El inventario no sustituye el catálogo de aplicaciones, el registro de riesgos, la CMDB, el mapa de datos o el inventario de proveedores. Los conecta alrededor de un caso de uso de IA. Esa relación evita mantener cinco listas que utilizan nombres distintos y no permiten reconstruir el recorrido completo.
Registra el sistema y el caso de uso, no solo el nombre del modelo
Utiliza como unidad principal el sistema dentro de un contexto de uso. Un mismo modelo puede resumir notas internas, redactar correos y actualizar el CRM; cada recorrido tiene datos, efectos y controles distintos. También varios modelos pueden formar parte de un solo servicio comercial. Registrar únicamente el nombre del modelo oculta estas diferencias.
Asigna un identificador estable y un nombre comprensible: función, proceso y alcance. Por ejemplo, copiloto para preparar seguimiento de oportunidades en México. Vincula el producto visible con sus modelos, recuperación, herramientas, reglas, interfaz y sistemas externos. Así se puede actualizar un componente sin perder la historia del caso de uso.
Separa registros cuando cambien de forma material las personas afectadas, la decisión, la autoridad, la clase de datos o el entorno. No crees otra fila por cada prompt menor. La granularidad correcta permite asignar responsabilidad y revisar riesgos sin convertir el inventario en un volcado técnico imposible de mantener.
Descubre usos aprobados, experimentales y no autorizados
Empieza con compras, contratos, inicio de sesión, integraciones, repositorios, cuentas de nube, extensiones, conectores, automatizaciones y entrevistas por proceso. Pregunta qué tareas reciben ayuda de IA, no solo qué herramientas de IA utiliza la persona. Una función integrada en CRM, correo o documentos puede pasar inadvertida porque no se adquirió como producto independiente.
Incluye desarrollo interno, servicios externos, funciones incorporadas, modelos abiertos, hojas conectadas a APIs y pruebas de una sola persona. Busca también herramientas dadas de baja que conservan datos, tokens o jobs. Contrasta hallazgos con líderes de Ventas, RevOps, Tecnología, Datos, Seguridad, Privacidad, Compras y Soporte.
Un uso no autorizado se registra con acceso restringido y una ruta de decisión; no se normaliza por aparecer en el inventario. Conserva el mínimo de evidencia necesario, contiene datos o permisos expuestos y decide si se retira, evalúa o reemplaza. El objetivo es recuperar control, no castigar el reporte honesto.
Captura campos que permitan decidir y actuar
La ficha mínima contiene identificador, nombre, propósito, área, usuarios, personas afectadas, decisión o tarea apoyada, estado, responsable de negocio, responsable técnico y contacto de operación. Añade fecha de alta, última revisión, próxima revisión, entorno, región y criticidad. Cada campo debe responder una pregunta de gobierno o recuperación.
Documenta entradas, salidas, fuentes, clases de datos, conservación, ubicación, modelos, proveedores, versiones, integraciones, herramientas, permisos y puntos de aprobación humana. Enlaza la arquitectura, evaluación, registro de riesgos, contrato, incidente y plan de continuidad en lugar de copiar documentos completos dentro de una celda.
Registra límites y uso prohibido. Una descripción como asistente comercial es demasiado amplia. Especifica si puede observar, resumir, recomendar, redactar, guardar, enviar o modificar; en qué sistemas; y bajo qué condición. La autoridad real importa más que la etiqueta copiloto o agente.
Utiliza estados de ciclo de vida con criterios de entrada y salida
Define estados que correspondan a decisiones reales. Candidato significa que existe una propuesta todavía no evaluada. Experimento limita datos, usuarios y efectos. Piloto prueba el recorrido con una cohorte y criterios. Producción habilita un alcance aprobado. Pausado contiene temporalmente. Retirado cierra operación y conserva evidencia según necesidad.
Cada transición exige responsable, fecha y evidencia. Pasar de experimento a piloto puede requerir caso de uso, datos autorizados y prueba inicial. Producción requiere aprobación, controles, monitoreo, soporte y fallback. Retirado requiere tratar datos, identidades, integraciones y dependencias. No utilices activo o inactivo como únicos estados.
Conserva el historial. Una fila retirada no se borra si todavía explica una decisión, un incidente, un dato conservado o una dependencia. Marca la versión final y las excepciones pendientes. Si el sistema vuelve, reabre la evaluación en lugar de cambiar silenciosamente el estado anterior.
| Criterio | Qué significa | Evidencia mínima para avanzar |
|---|---|---|
| Candidato | Uso propuesto, todavía no autorizado | Propósito, dueño y materialidad inicial |
| Experimento | Prueba aislada sin efecto productivo | Límites, datos seguros y fecha de cierre |
| Piloto | Cohorte y escenarios controlados | Criterios, controles, soporte y decisión |
| Producción | Alcance aprobado y monitoreado | Versión, responsables, evidencia y fallback |
| Pausado | Contención temporal o revisión | Causa, autoridad y condición de reanudación |
| Retirado | Uso cerrado con trazabilidad | Datos, accesos, dependencias y verificación tratados |
Asigna propietarios de negocio, tecnología, datos y control
El responsable de negocio confirma propósito, usuarios, decisión y continuidad. El responsable técnico mantiene componentes, versión e integración. El dueño de datos autoriza fuentes y calidad. Quien opera un control conserva su configuración y evidencia. Una persona puede ocupar varios papeles en un equipo pequeño, pero las funciones deben seguir visibles.
Registra suplencia y autoridad: quién aprueba el alta, quién acepta riesgo residual, quién puede pausar y quién autoriza reanudar o retirar. Un alias de equipo facilita contacto, pero no sustituye a una persona responsable. Revisa registros huérfanos cuando alguien cambia de función o deja la empresa.
Evita convertir al área de seguridad en propietaria de todos los sistemas. Seguridad aporta criterios y controles; el área que obtiene el beneficio debe responder por el caso de uso y su operación. La responsabilidad compartida se documenta mediante tareas concretas, no con una etiqueta general.
Mapea datos, identidad, permisos y efecto posible
Clasifica datos de entrada, contexto recuperado, salida, feedback y telemetría. Registra fuente oficial, finalidad, región, conservación y personas que pueden acceder. Distingue información pública, interna, confidencial, personal, sensible, credenciales y material de terceros. Una fuente disponible no se vuelve autorizada por estar conectada.
Documenta identidades humanas y de servicio, secretos, roles, ámbitos y acciones. Separa lectura, escritura, envío y administración. Indica si el sistema puede actuar sobre una oportunidad, una cuenta, todo el espacio o un servicio externo. Microsoft recomienda inventariar, validar, versionar y monitorear modelos, herramientas, complementos y fuentes utilizados por agentes.
Relaciona cada permiso con la tarea que lo justifica y prueba su revocación. El inventario debe mostrar cuándo un sistema conserva acceso que ya no necesita. En una revisión, la pregunta no es solo qué datos usa, sino qué podría consultar o modificar con la autoridad actual.
Conecta componentes, proveedores y dependencias compartidas
Representa aplicación, modelos, prompts, recuperación, índices, herramientas, conectores, APIs, nube, identidad y observabilidad como componentes vinculados. Registra versión y proveedor cuando corresponda. Mapear todos los componentes permite aplicar el resultado de Map 4 del AI RMF: comprender riesgos y beneficios de software y datos de terceros dentro del sistema completo.
Identifica consumidores aguas abajo. Una salida puede alimentar un correo, una propuesta, una métrica o una automatización. También busca dependencias comunes: varios sistemas pueden usar el mismo modelo, proveedor de identidad o catálogo. Esta concentración modifica continuidad e impacto aunque cada caso parezca independiente.
Mantén enlaces estables entre el registro principal y los componentes. Una actualización del modelo no debería crear un sistema nuevo si el caso de uso permanece, pero debe cambiar la versión y activar revisión. Una nueva herramienta con permiso de escritura puede modificar materialmente el alcance y requerir otra evaluación.
Prioriza la revisión según impacto, autoridad y exposición
El inventario no necesita el mismo nivel de detalle para todos los registros desde el primer día. Prioriza sistemas que afectan personas, decisiones, dinero, acceso, información sensible, compromisos externos o continuidad. Considera alcance de usuarios, frecuencia, reversibilidad, autonomía, terceros, novedad y calidad de evidencia.
Define niveles con criterios observables y actividades asociadas. Un nivel alto puede exigir evaluación independiente, revisión legal, prueba adversaria, aprobación ejecutiva, monitoreo reforzado y cadencia corta. Un nivel bajo no significa sin controles; puede seguir necesitando dueño, propósito, datos permitidos y fecha de revisión.
No presentes el nivel como probabilidad medida si no existe esa evidencia. La priorización asigna recursos y orden de revisión. El riesgo específico se documenta en el registro correspondiente con escenario, controles, evidencia y residual.
Enlaza evidencia sin convertir el inventario en un archivo muerto
El registro debe apuntar a documentos vigentes: arquitectura, evaluación, política aplicable, revisión de proveedor, contrato, prueba de permisos, registro de riesgos, plan de incidente, monitoreo y salida. Guarda identificador, propietario, versión y fecha. Un enlace roto o un documento sin alcance no demuestra que el sistema siga controlado.
Añade indicadores de calidad del propio inventario: registros sin dueño, revisión vencida, versión desconocida, producción sin fallback, permisos no confirmados, evidencia caducada y componentes sin consumidor. Estas señales permiten corregir deuda antes de que aparezca durante un incidente.
Minimiza la información sensible. El inventario puede contener referencias a secretos o datos restringidos sin copiar sus valores. Limita acceso según función y registra cambios. La transparencia interna necesaria para gobernar no obliga a exponer arquitectura o datos a todas las personas.
Actualiza por eventos, revisiones periódicas y conciliación
Define responsables de actualización y disparadores automáticos o manuales. Alta de proveedor, nuevo modelo, integración, fuente, permiso, entorno, grupo de usuarios, incidente, deprecación, cambio contractual, pausa y retiro deben revisar el registro. Etiqueta eventos con el identificador del sistema para conservar relaciones.
Realiza una conciliación periódica con compras, SSO, nube, repositorios, integraciones, contratos y entrevistas. La ausencia de cambios reportados no demuestra que el inventario esté completo. Busca registros sin actividad, herramientas nuevas y servicios retirados que todavía reciben tráfico o conservan acceso.
Cada revisión termina en mantener, completar, limitar, evaluar, pausar, reanudar, consolidar o retirar. Conserva quién decidió, evidencia nueva y próxima condición. Mide cobertura y vigencia, no el número bruto de filas: descubrir más sistemas puede mejorar el control aunque el total aumente.
Registra Cerravi con sus capacidades y límites actuales
En un inventario organizacional, Cerravi debe aparecer por los casos de uso realmente habilitados. El copiloto organiza contexto y propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente. Las propuestas utilizan productos y precios disponibles en el catálogo. Un importe faltante exige confirmación y las monedas permanecen separadas salvo conversión aprobada.
La actividad de Buyer Room aporta señales de interacción, pero no confirma identidad, aceptación, contrato, pago o intención. Forecast utiliza reglas transparentes del CRM; no es un modelo predictivo entrenado o calibrado como machine learning y no garantiza cierres o ingresos.
La empresa debe registrar sus usuarios, datos, permisos, configuraciones, integraciones, responsables, controles y decisiones aplicables. No atribuyas al producto una región, subprocesador, certificación, retención o condición contractual que no esté confirmada en la documentación vigente y el acuerdo correspondiente.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Qué cuenta como sistema de IA dentro del inventario?
Todo caso de uso que emplee un sistema o componente de IA para generar, resumir, clasificar, recomendar o ejecutar dentro de un proceso. Incluye productos comprados, funciones incorporadas, desarrollo interno, modelos abiertos, APIs, automatizaciones y experimentos.
¿Conviene registrar cada modelo como una fila distinta?
No siempre. La unidad principal debe ser el sistema en su contexto de uso. Los modelos se vinculan como componentes con versión y proveedor. Separa filas cuando cambien de forma material la decisión, personas afectadas, datos, autoridad o entorno.
¿Qué hacer con herramientas de IA no autorizadas?
Regístralas con acceso restringido, contiene datos y permisos si existe exposición y abre una decisión para retirar, evaluar o reemplazar. Incluirlas en el inventario no equivale a aprobarlas.
¿Quién debe mantener el inventario de sistemas de IA?
Puede existir una coordinación central, pero cada registro necesita dueño de negocio y responsable técnico. Datos, Seguridad, Privacidad, Compras, Legal y Operación mantienen los campos y evidencias que les corresponden.
¿Con qué frecuencia debe revisarse el inventario?
Según la prioridad de riesgo y también cuando cambien modelo, datos, permisos, proveedor, integración, usuarios, entorno o estado. Además conviene conciliar periódicamente el inventario con fuentes como compras, SSO, nube, repositorios y contratos.