Ya tienes IA en producción. El inventario que ISO 42001 te va a pedir.

Dónde está la IA que no inventariaste

Cuando un equipo se sienta a listar sus sistemas de IA, la lista sale corta y ordenada: el copiloto de código, la herramienta de marketing, tal vez un chatbot. Tres o cuatro nombres. La lista real es más larga, y casi siempre incluye estos cinco lugares.

El SaaS que activó IA por default. Tu CRM, tu mesa de ayuda, tu suite ofimática. Nadie firmó un contrato nuevo ni evaluó un proveedor: la función llegó en un release y quedó encendida. El resumen automático de tickets que ahora lee todos tus casos de soporte entró así.

La API key en el código. Alguien de producto conectó un modelo hace ocho meses para una funcionalidad puntual. Funciona bien, nadie la tocó desde entonces, y no aparece en ningún registro porque nunca fue un proyecto: fue una tarde.

El proveedor que metió IA en su producto y no te avisó. Tu procesador de nómina ahora usa un modelo para detectar anomalías. Tu contrato no lo menciona porque se firmó antes de que existiera. Sigue siendo tu proveedor, sigue procesando tus datos, y ahora hace algo que no evaluaste.

Las extensiones y asistentes del navegador. Transcriptores de reuniones, resumidores de correo, tomadores de notas. Los instala una persona, con su cuenta, y quedan con acceso a todo lo que esa persona ve. Casi nunca pasan por un inventario de activos porque no se perciben como software corporativo.

Los agentes. Lo más nuevo y lo menos inventariado. La diferencia con un chatbot no es de grado: un agente no sólo responde, ejecuta acciones contra tus sistemas. Crea tickets, manda correos, modifica registros. El inventario de un sistema que actúa tiene que registrar cosas que el de un sistema que sólo responde no necesita.

Nótese el patrón: cuatro de esos cinco no los introdujo el área de tecnología. Por eso un inventario que se levanta preguntándole a TI sale incompleto por diseño.

Una lista de herramientas no es un inventario

El inventario típico tiene tres columnas: nombre del producto, área que lo usa, si es pago. Es un buen registro de compras. Como inventario de sistemas de IA no sirve, porque 42001 no te pregunta qué herramientas tienes. Te pregunta qué sistemas operas y qué consecuencias tienen.

Un inventario útil responde cinco preguntas por cada sistema:

• Qué decide o influye. ¿Recomienda, prioriza, filtra, puntúa, redacta, aprueba? El verbo importa: "aprueba" y "sugiere" no generan las mismas obligaciones.
• Sobre quién recae esa decisión. Un cliente, un postulante, un empleado, un proveedor — o nadie, porque el sistema optimiza una ruta de despacho y no afecta a ninguna persona identificable.
• Con qué datos se alimenta. Públicos, propios, personales, sensibles. Y de dónde salieron.
• Quién puede revertir la decisión, y cómo. Si la respuesta es "nadie revisa" o "en teoría el analista, pero llegan 400 al día", eso es un dato del inventario, no una vergüenza que ocultar.
• Qué pasa si se equivoca. Un resumen mal hecho se corrige leyendo el original. Un scoring mal calibrado le niega un servicio a alguien que califica.

El nombre del producto no es un campo interesante. Las respuestas a esas cinco preguntas son las que determinan qué controles del Anexo A te aplican y con qué profundidad. Un inventario que las tiene pobladas es el insumo de todo lo demás; uno que sólo tiene nombres obliga a levantar la información de nuevo, entrevista por entrevista, cuando llegue el momento de la evaluación de impacto.

El campo que casi todos omiten: tu rol frente al sistema

Desarrollar un modelo, ajustarlo con tus propios datos o consumirlo por API son tres posiciones distintas frente a la misma tecnología. La norma trata a la organización según el rol que cumple respecto de cada sistema, no según lo que la organización es en general.

La consecuencia práctica es la que más se pasa por alto: la misma empresa puede ser desarrolladora de un sistema y usuaria de otros doce. Un inventario que asigna un rol a la empresa —"somos usuarios de IA"— en vez de un rol por sistema no aguanta la primera repregunta.

Y cambia qué evidencia tienes que producir. Si desarrollas, tienes que poder mostrar con qué datos entrenaste, cómo evaluaste el desempeño y qué hiciste respecto del sesgo. Si consumes por API, tu obligación se corre hacia dos lados: el due diligence del proveedor y el uso —qué le mandas, qué haces con la respuesta, y qué le dijiste al usuario final sobre que hay un modelo de por medio.

Son cargas de prueba distintas. Una empresa que se declara "usuaria" en bloque y tiene un modelo afinado con sus datos de clientes está declarando mal, y lo va a descubrir en el peor momento.

"No hay IA" y "no miramos" no son lo mismo

Este es el error que más caro sale, y es de forma, no de contenido: un inventario que dice cero sistemas porque nadie revisó se ve idéntico a uno que revisó y no encontró nada. Sólo uno de los dos aguanta una auditoría, y desde afuera no se distinguen.

La diferencia se hace registrando la cobertura, no sólo el resultado. Comparemos dos afirmaciones:

• "No usamos IA." — No es auditable. No dice quién lo determinó, cómo, ni cuándo.
• "Revisamos las 40 aplicaciones del catálogo SaaS y los repositorios con actividad en los últimos 12 meses. Encontramos 3 sistemas. No revisamos extensiones de navegador ni los productos de proveedores externos; queda pendiente para el próximo ciclo." — Es auditable, y además es honesta sobre su propio límite.

La segunda tiene tres sistemas y dos huecos declarados. La primera tiene cero sistemas y un hueco del tamaño de la empresa. En una revisión, la segunda va mucho mejor: un hallazgo abierto y conocido es un programa funcionando; un cero sin respaldo es un programa que no empezó.

Ese mismo mecanismo explica por qué los inventarios envejecen mal. Se arman una vez, quedan en verde, y nadie vuelve porque no hay nada que los contradiga. Seis meses después hay tres sistemas nuevos y el documento sigue diciendo cinco — sin que ninguna alarma suene, porque un inventario desactualizado se ve exactamente igual que uno al día.

El inventario dispara dos evaluaciones distintas, no una

Acá hay un cruce que en Chile va a aparecer mucho en los próximos meses, y conviene tenerlo claro antes de empezar.

La evaluación de impacto de sistemas de IA del requisito 6.1.4 pregunta qué impacto tiene el sistema sobre individuos, grupos y la sociedad. El sujeto está afuera de la organización. No es la evaluación de riesgo del SGSI, que pregunta qué riesgo corre la organización: es la inversión del sujeto.

La DPIA de la Ley 21.719 pregunta por el tratamiento de datos personales y sus riesgos para los titulares.

Se solapan, pero no se sustituyen. Un sistema de IA puede no tratar ni un dato personal y aun así requerir evaluación de impacto bajo 42001 — un modelo que prioriza mantenimiento de infraestructura crítica, por ejemplo. Y un tratamiento puede necesitar DPIA sin que haya ningún modelo involucrado. Presentar una en lugar de la otra es un hallazgo.

Lo aprovechable es que las dos se alimentan del mismo inventario. Si los campos "sobre quién recae la decisión" y "con qué datos se alimenta" están bien poblados, las dos evaluaciones salen del mismo levantamiento. Si el inventario es una lista de nombres, hay que hacer el trabajo dos veces, con dos equipos, entrevistando a la misma gente.

Con la vigencia plena de la Ley 21.719 el 1 de diciembre de 2026, muchos equipos chilenos van a estar levantando su RAT en el mismo trimestre. Es la misma entrevista. Hacerla por separado es pagar dos veces.

Por dónde empezar esta semana

Tres pasos, sin comprar nada y sin abrir un proyecto.

1. Empieza por las preguntas, no por los nombres

Una hoja con las cinco columnas de más arriba. Si la primera columna es el nombre del producto, el ejercicio se convierte en un listado de compras y se detiene ahí. Si la primera columna es "qué decide", cada fila obliga a pensar.

2. Tres fuentes, no una encuesta

Preguntarle a la gente "¿usas IA?" produce falsos negativos, porque mucha gente no considera "IA" a la función de resumen que su herramienta trae incorporada. Pregunta por tareas, no por tecnología: "¿algo te sugiere, prioriza, redacta o clasifica automáticamente?". Y contrasta con dos fuentes que no dependen de la memoria de nadie:

• La facturación y el catálogo de SaaS. Las funciones de IA casi siempre se cobran aparte o cambian el plan. La factura sabe cosas que el usuario olvidó.
• Los repositorios. Una búsqueda de las librerías y los dominios de los proveedores de modelos encuentra en minutos lo que una encuesta no encuentra nunca.

3. Registra lo que no miraste, con fecha

Es el paso que casi todos se saltan y el que convierte una lista en un documento defendible. Dos líneas al pie: qué quedó fuera del alcance de esta pasada y cuándo se revisa.

Qué reusas de ISO 27001 y qué no

Si ya tienes un SGSI certificado, buena parte del trabajo está hecho. Las cláusulas 4 a 10 de 42001 son la estructura armonizada que comparten las normas ISO de sistemas de gestión: alcance, liderazgo, competencias, comunicación, auditoría interna, revisión por la dirección, mejora. Todo eso se reusa con ajustes de contenido, no de estructura.

Lo que no se reusa es el Anexo A. ISO/IEC 42001 trae 38 controles propios, en el rango A.2 a A.10, que no tienen equivalente en los 93 del Anexo A de 27001. Y su Declaración de Aplicabilidad es un documento separado: aunque las dos se llamen SoA, no se fusionan. Presentar una sola SoA que mezcle los controles de ambas normas no es una optimización, es un hallazgo.

El resumen honesto del reuso: la mitad de management system se hereda casi entera, y la parte específica de IA —inventario, evaluación de impacto, controles del Anexo A, política de uso responsable— hay que construirla. Que sea menos trabajo del que parece no significa que sea automático.