Gobierno, privacidad y riesgo de IA en la empresa: inventario, controles y responsabilidad · Módulo 1: Inventario y clasificación

Crear un inventario de usos, modelos y responsables

Inventario vivo por caso de uso que registra finalidad, personas, datos, componentes, proveedor, autonomía, propietarios y ciclo de vida.

Objetivo de aprendizaje

Construir un inventario de IA que permita localizar cada caso, distinguir componentes y roles y asignar responsabilidades de negocio, técnica y control.

El gobierno de IA empieza por una pregunta aparentemente administrativa: ¿qué sistemas de IA utiliza realmente la organización y para qué?. Si la respuesta depende de preguntar informalmente a cada equipo, todavía no existe una base suficiente para gobernar riesgos, datos, proveedores ni obligaciones.

Un inventario útil no es una lista de herramientas. Debe describir casos de uso. La misma aplicación puede intervenir en tareas muy distintas: redactar un correo, resumir documentos, priorizar candidatos, generar código, clasificar solicitudes o ejecutar acciones mediante herramientas. El riesgo, los datos y el papel de la organización cambian con la finalidad.

Define la unidad de inventario

Registra una entrada por combinación significativa de:

finalidad + usuarios + personas afectadas + datos + sistema + autonomía

No abras una ficha por cada prompt. Tampoco agrupes todos los usos de un proveedor en una sola fila.

Una entrada razonable puede ser:

«Asistente generativo utilizado por el equipo comercial para preparar borradores de propuestas a partir de documentación interna autorizada».

Otra entrada distinta sería:

«Sistema que puntúa automáticamente oportunidades y decide qué leads reciben seguimiento prioritario».

Aunque utilicen el mismo modelo, la función organizativa y las consecuencias no son equivalentes.

Campos mínimos

Cada registro debería poder responder:

  • identificador del caso;
  • nombre y descripción;
  • finalidad;
  • proceso empresarial;
  • propietario de negocio;
  • responsable técnico;
  • usuarios;
  • personas potencialmente afectadas;
  • resultado o decisión producida;
  • grado de autonomía;
  • revisión humana;
  • datos de entrada;
  • datos de salida;
  • categorías especiales o información sensible si procede;
  • modelo o familia de modelos cuando se conozca;
  • proveedor y producto;
  • plan o tipo de cuenta;
  • sistemas conectados;
  • herramientas que puede ejecutar;
  • repositorios consultados;
  • ubicación o región cuando sea relevante;
  • estado: idea, evaluación, piloto, producción, suspendido o retirado;
  • fecha de última revisión;
  • siguiente revisión;
  • riesgos abiertos;
  • evidencias asociadas.

El inventario debe admitir que algunos detalles todavía sean desconocidos. Un campo unknown visible es mejor que completar información por intuición.

Registra el papel real de la organización

En regulación, contratos y privacidad importa si la empresa desarrolla, comercializa, integra, modifica o simplemente utiliza un sistema. No deduzcas el papel jurídico a partir del nombre interno del proyecto.

El AI Act distingue operadores como proveedores y deployers, entre otros. Una organización puede desempeñar roles distintos en proyectos diferentes. Además, adaptar sustancialmente un sistema, comercializarlo bajo nombre propio o integrarlo en otra solución puede exigir un análisis más cuidadoso.

El inventario debe incluir un campo de rol preliminar, acompañado de needs_legal_review cuando no esté claro. El inventario facilita la revisión; no sustituye la interpretación jurídica.

Mapea componentes, no solo la interfaz visible

Una herramienta SaaS puede depender de:

  • proveedor de modelo;
  • almacenamiento;
  • conectores;
  • OCR;
  • búsqueda;
  • servicios de moderación;
  • APIs externas;
  • subencargados;
  • herramientas propias.

Registra la cadena suficientemente bien para saber por dónde pasan los datos y qué componente produce cada efecto. «Usamos Asistente X» puede ser insuficiente si la aplicación además consulta SharePoint, envía archivos a otro servicio y escribe en el CRM.

Define propietarios diferentes

Un único «responsable del sistema» suele ocultar varias decisiones.

Conviene distinguir, cuando proceda:

Propietario de negocio. Responde por finalidad, necesidad y uso.

Responsable técnico. Responde por integración, configuración y operación.

Privacidad. Evalúa cuestiones de protección de datos cuando sean aplicables.

Seguridad. Revisa amenazas, accesos y dependencias.

Compras/procurement. Mantiene evidencia contractual y de proveedor.

Legal/compliance. Interpreta obligaciones aplicables.

Usuario operativo. Ejecuta y aporta feedback.

Una persona puede ocupar varios roles en una organización pequeña, pero las responsabilidades deben seguir diferenciadas.

Clasifica autonomía

No uses solo «manual» o «automático». Documenta qué puede hacer el sistema:

  1. recomienda;
  2. prepara borrador;
  3. clasifica;
  4. decide dentro de reglas;
  5. ejecuta una acción reversible;
  6. ejecuta una acción con efecto externo;
  7. encadena herramientas o decisiones.

Registra dónde interviene una persona y qué puede cambiar. «Hay un humano en el proceso» no prueba que exista supervisión efectiva.

Descubre shadow AI

El inventario formal no sirve si ignora usos reales de empleados. Busca:

  • cuentas personales utilizadas para trabajo;
  • extensiones del navegador;
  • asistentes incorporados en SaaS;
  • funciones generativas activadas por defecto;
  • scripts de equipos;
  • APIs contratadas con tarjetas individuales;
  • herramientas de transcripción;
  • generadores de imágenes, vídeo o código.

El objetivo no es castigar el uso no inventariado. Es hacerlo visible para aplicar condiciones proporcionales.

Mantén historial

Una ficha debe conservar cambios:

  • modelo;
  • proveedor;
  • finalidad;
  • datos;
  • permisos;
  • autonomía;
  • población afectada;
  • estado;
  • revisión.

No sobrescribas silenciosamente un cambio material. La trazabilidad permite saber qué configuración estaba activa cuando ocurrió una incidencia.

Métricas del inventario

No midas solo «número de casos registrados». Observa:

  • porcentaje con propietario;
  • porcentaje con revisión vigente;
  • casos sin proveedor identificado;
  • casos con datos personales;
  • casos con efectos externos;
  • casos sin plan de salida;
  • casos con riesgo abierto;
  • casos no utilizados en los últimos meses.

Estas métricas ayudan a priorizar trabajo, no a declarar cumplimiento.

Ejemplo

Un equipo usa un asistente para revisar contratos internos. El registro identifica:

  • finalidad: preparar un resumen para el abogado;
  • usuarios: equipo jurídico;
  • datos: contratos potencialmente confidenciales;
  • sistema: cuenta empresarial;
  • integración: repositorio documental;
  • autonomía: solo borrador;
  • supervisor: abogado;
  • proveedor: tercero;
  • estado: piloto;
  • riesgo abierto: verificar conservación y subencargados;
  • siguiente revisión: antes de producción.

El sistema no se clasifica automáticamente como «bajo riesgo» solo porque haya revisión humana.

Ejercicio

Construye un inventario inicial con diez casos reales. Incluye al menos:

  • un asistente general;
  • una función de IA integrada en SaaS;
  • un sistema con datos personales;
  • una automatización con tool calling;
  • un uso no aprobado;
  • un caso retirado.

Para cada uno completa propietarios, datos, personas afectadas, autonomía, proveedor, estado y próxima revisión.

Después pregunta a otro equipo si podría determinar, solo con esa ficha, qué necesita revisar antes de cambiar el sistema.

Resultado de la lección

Debes terminar con un inventario vivo que represente casos, componentes, personas, datos, responsabilidades y ciclo de vida. La siguiente lección utiliza esa información para priorizar qué casos requieren más análisis, sin confundir una matriz interna con una clasificación jurídica.