Qué información recoger en cada ficha del inventario
Una ficha útil permite saber de qué hablamos, cómo se utiliza y dónde encontrar la información que sustenta las decisiones.
Recupera la decisión de registro de la lección 4.1 y los hallazgos de la 4.2. Tiempo orientativo: 15 minutos de lectura y 25 de práctica.
La lección de un vistazo
Cada campo debe ayudar a responder una pregunta
Después de localizar los usos de IA, necesitamos ordenar lo descubierto. Una ficha extensa puede parecer completa y seguir sin aclarar quién recibe una salida o si alguien la revisa antes de aplicarla.
Empieza por las preguntas de gestión: qué existe, para qué se utiliza, en qué entorno, quién lo conoce y qué condiciones están confirmadas. Después añade el detalle que resulte necesario. La plantilla de esta lección es una propuesta didáctica adaptable, no un formulario obligatorio de ISO/IEC 42001.
No confundas cantidad con calidad. Una descripción precisa con lagunas identificadas permite trabajar mejor que una tabla llena de suposiciones.
Separar la ficha del sistema y la ficha del uso
Como criterio de trabajo del módulo, mantendremos los datos compartidos en una ficha de sistema y las condiciones particulares en fichas de uso vinculadas. En entornos sencillos pueden ser secciones de un mismo documento; lo importante es conservar la relación.
Ficha del sistema
Identifica la solución y sus componentes conocidos: nombre, proveedor si está confirmado, versión o referencia disponible, entorno, integraciones y responsable de mantener la información común.
Ficha del uso
Describe la finalidad, el proceso, las personas, las entradas, las salidas, cómo se aplican, la supervisión y las condiciones de autorización de una actividad concreta.
Un uso puede depender de varios sistemas y un sistema puede servir a varios usos. Si necesitas registrar varias relaciones, hazlas explícitas. No fuerces una correspondencia de uno a uno si el servicio no funciona así.
Utiliza identificadores estables, por ejemplo SYS-001 y USO-001. Son convenciones propuestas para el ejercicio. Un cambio de nombre comercial no debería hacer perder la relación con las decisiones y registros anteriores.
La ficha del sistema: información compartida
| Grupo de campos | Qué recoger | Para qué sirve |
|---|---|---|
| Identidad y ámbito | Identificador, nombre, descripción, área y relación con el alcance del SGIA. | Reconocer la solución y evitar duplicados. |
| Origen y componentes | Desarrollo propio o servicio externo; proveedor, modelo o componentes cuando se conozcan. | Localizar dependencias y puntos de contacto. |
| Versión y entorno | Referencia de versión disponible, despliegue o configuración relevante; prueba o entorno operativo. | Saber a qué situación se refiere la ficha. |
| Conexiones | Sistemas, fuentes o servicios con los que se integra; referencias a documentación técnica. | Entender qué puede verse afectado por un cambio. |
| Responsables | Funciones responsables del sistema, soporte técnico y mantenimiento del registro. | Saber quién responde y quién actualiza la información. |
| Evidencias y mantenimiento | Fuentes, fecha de comprobación, referencias relacionadas, pendientes y motivo de próxima revisión. | Valorar la fiabilidad y vigencia de los datos. |
No siempre conocerás la versión exacta de un modelo proporcionado como servicio. Registra la referencia que el proveedor expone, cómo se obtuvo y la limitación. No escribas «última versión» como si fuera una identificación estable ni inventes componentes internos.
Una persona puede mantener la ficha sin tener autoridad para aprobar el uso del sistema. Identifica las funciones con precisión y relaciónalas con las responsabilidades trabajadas en el módulo 3.
La ficha de uso: dónde aparecen las condiciones concretas
| Grupo de campos | Pregunta que debe responder |
|---|---|
| Identidad y relación | ¿Cuál es el identificador del uso y con qué sistemas se relaciona? |
| Finalidad y límites | ¿Qué tarea ayuda a realizar y qué queda fuera de las condiciones definidas? |
| Proceso y personas | ¿Quién lo utiliza, quién recibe el resultado y quién puede verse afectado? |
| Entradas y fuentes | ¿Qué categorías de datos recibe y de dónde proceden? |
| Salidas y aplicación | ¿Qué produce y qué ocurre después: revisión, envío, recomendación o ejecución? |
| Intervención humana | ¿Quién comprueba, corrige o detiene la actuación, con qué procedimiento y límites? |
| Estado y autorización | ¿Se utiliza realmente, en qué etapa está y qué decisión sustenta las condiciones permitidas? |
| Dependencias y seguimiento | ¿Qué recursos o servicios necesita, qué documentación lo desarrolla y qué queda por comprobar? |
Describe los datos mediante categorías y referencias suficientes. La ficha de inventario no necesita contener contraseñas, claves de acceso ni copias de tickets con datos personales. La evidencia detallada puede mantenerse en un repositorio protegido, con una referencia y permisos adecuados.
«Supervisión humana» es demasiado genérico. Aclara en qué momento interviene alguien y qué puede hacer. Si el procedimiento o la práctica real no están confirmados, dilo. Marcar una casilla no demuestra que exista una supervisión efectiva.
Estados que no conviene mezclar
Evita que una única columna «estado» signifique cosas distintas para cada persona. Para el ejercicio, separaremos estas dimensiones y acordaremos el significado de sus valores:
- Confirmación: candidato por contrastar o uso de IA confirmado con una fuente identificada.
- Etapa o situación operativa: propuesto, piloto, en uso, suspendido o retirado, según corresponda.
- Autorización: condiciones autorizadas con referencia a la decisión, pendientes de localizar o pendientes de decisión; otras situaciones deben describirse con precisión.
- Calidad del registro: información verificada en determinados campos, incompleta o pendiente de revisión.
Un piloto puede estar autorizado con límites. Un uso operativo puede tener una autorización todavía no localizada por quien elabora la ficha. Un registro revisado puede seguir mostrando una decisión pendiente. Ninguna de estas dimensiones sustituye a las otras.
No incorpores una etiqueta de «riesgo bajo» solo para rellenar la ficha. La evaluación de riesgos e impactos se trabajará en los módulos siguientes. Por ahora puedes enlazar una evaluación existente, indicando su ámbito y fecha, o registrar señales que requieren revisión sin convertirlas en una conclusión formal.
Registrar lo desconocido de forma que se pueda resolver
Una celda vacía puede significar que no aplica, que nadie lo ha preguntado o que se ha comprobado y no se conoce. Utiliza expresiones que distingan esas situaciones.
| Anotación | Cómo completarla |
|---|---|
| Pendiente de confirmar | Qué falta, con quién se contrastará y cuándo se revisará. |
| No aplicable | Motivo y ámbito al que se refiere. No utilizarlo para ocultar desconocimiento. |
| No facilitado o no disponible | Fuente consultada, limitación y decisión o acción que puede requerir. |
| Confirmado | Fuente, fecha y alcance de la comprobación; evitar extenderla a otros entornos. |
La fuente puede ser una configuración observada, documentación aplicable, una decisión registrada o una entrevista. Indica qué permite concluir cada una. Una declaración sobre el uso habitual no confirma por sí sola la configuración técnica.
La fecha de modificación de la ficha tampoco equivale a la fecha en la que se comprobó cada dato. Diferenciarlas ayuda a reconocer qué información necesita una nueva revisión.
TechServe IT: dos usos del copiloto, una relación visible
Propuesta didáctica basada en el caso. Creamos SYS-001 para identificar el copiloto de técnicos y proponemos USO-001 para la generación de código y USO-002 para la redacción de respuestas. La separación se revisará si las comprobaciones de la lección 4.1 aconsejan otro diseño.
Sabemos que el copiloto propone código y respuestas. No conocemos todavía su proveedor, su modelo, las categorías exactas de datos ni cómo se revisa cada salida.
| Campo de ejemplo | Registro propuesto para USO-002 |
|---|---|
| Sistema relacionado | SYS-001 · Copiloto para técnicos. Identificador propuesto para el ejercicio. |
| Finalidad | Proponer respuestas para técnicos. Concretar en qué tareas y canales se utilizan. |
| Entradas | Categorías y procedencia pendientes de confirmar con quienes utilizan el copiloto. |
| Salida y aplicación | Propuestas de respuesta; revisión y forma de envío pendientes de contraste. |
| Responsable del uso | Función pendiente de designación o confirmación; consultar al responsable del servicio. |
| Autorización | Pendiente de localizar la decisión y sus condiciones. No concluir que no existe. |
| Fuente | Descripción del caso formativo; no es evidencia de una implantación real. |
Una ficha honesta no es una ficha terminada. Lo que la hace útil es que las lagunas se conviertan en comprobaciones y decisiones asignadas. Antes de usar esta estructura en un servicio real, sustituye las hipótesis por datos contrastados y conserva la trazabilidad.
Si ambos usos comparten proveedor, actualiza ese dato en la ficha del sistema y mantén la relación. Si sus condiciones de autorización son distintas, no copies una decisión de un uso al otro sin comprobar su alcance.
Evitar un inventario que nadie pueda mantener
Relaciona el inventario con lo que ya existe: registro de aplicaciones, base de datos de configuración del servicio, catálogo, contratos y procedimientos. Identifica dónde reside cada dato de referencia para no mantener varias copias contradictorias.
Define quién propone cambios, quién comprueba los datos y quién mantiene el registro. No todos los cambios necesitan la misma decisión: corregir un error de escritura y ampliar una finalidad son situaciones diferentes. La lección 4.5 desarrollará cómo mantener la información ante cambios y retiradas.
Una ficha completa es una ayuda para gobernar, no una prueba automática de seguridad, conformidad o autorización. El inventario permite llegar a las evidencias; no sustituye la evaluación ni las decisiones.
Tu actividad: una ficha de sistema y una de uso
Utiliza los hallazgos de la lección 4.2 o el copiloto de TechServe IT. Completa dos bloques relacionados, marca lo desconocido y elige las próximas comprobaciones. Si trabajas con un caso real, emplea descripciones sin información confidencial.
Criterios para revisar tu trabajo
- Los identificadores permiten relacionar el sistema con el uso sin ambigüedad.
- La finalidad describe una tarea y las salidas explican cómo se aplican.
- La intervención humana está descrita o marcada como pendiente de comprobación.
- Los estados operativos, de autorización y de verificación están separados.
- Los datos relevantes tienen una fuente y una fecha de comprobación.
- Las lagunas generan acciones; no se rellenan con suposiciones.
Orientación para resolver el caso
Utiliza SYS-001 y USO-002 como identificadores propuestos. Mantén «proveedor pendiente de confirmar» en la ficha del sistema y «forma de revisión y envío pendiente de contraste» en la del uso. Propón consultar a la administración de la herramienta y a quienes preparan las respuestas, distinguiendo qué pregunta resuelve cada fuente. No marques el uso como aprobado hasta localizar una decisión aplicable.
Repaso con respuestas explicadas
¿La ficha de uso debe repetir toda la información del proveedor?
No necesariamente. Puede referenciar la ficha del sistema y los documentos comunes. Las condiciones particulares del uso sí deben quedar identificadas.
¿Qué escribo si no conozco la versión del modelo?
La referencia disponible y su fuente, junto con la limitación y la comprobación pendiente. No inventes una versión ni uses «última» como si fuera una referencia estable.
¿Una ficha revisada significa que el uso está autorizado?
No. Revisar la calidad de un registro y autorizar una actividad son decisiones diferentes.
¿Debo rellenar la clasificación de riesgo aunque no se haya evaluado?
No. Indica que la evaluación está pendiente o enlaza una evaluación existente que realmente cubra ese uso. No conviertas una impresión en una clasificación formal.
Referencia y siguiente paso
Referencia complementaria: NIST AI RMF 1.0, GOVERN 1.6 ↗ (nueva pestaña), utilizado como orientación general sobre inventario. Los grupos de campos, identificadores y ejemplos de esta lección son propuestas didácticas propias; no son un formulario prescrito por ISO/IEC 42001.
Conserva tus fichas. En la lección 4.4 profundizaremos en responsables, usuarios, datos, proveedores y dependencias para comprobar que las relaciones del inventario reflejan el servicio real.
Escucha y aplica lo aprendido
Audio compartido por las lecciones 4.1–4.3
009. Inventario de IA: descubrir y registrar los usos en la empresa
Escucha el episodio y vuelve a la actividad de esta lección para aplicar sus ideas. Las precisiones siguientes forman parte del acompañamiento didáctico.
Precisiones para aplicar el episodio
La separación de usos en fichas debe justificarse por sus condiciones de gestión. Es una propuesta didáctica: el ejercicio no presupone que sea obligatoria.
En el caso base, el clasificador propone criticidad y destino; su aplicación automática está pendiente de comprobar. Un entorno de pruebas requiere verificar su aislamiento, datos, permisos y conexiones.
Confirmación, operación, autorización y calidad de información ayudan a organizar el registro. La autorización corresponde a las funciones con autoridad asignada, no necesariamente siempre a la dirección.