SAS AI Navigator empieza la gobernanza por el inventario. Vincular un caso de uso a una norma no es cumplirla

Pregunte a una gran empresa cuántos sistemas de IA tiene en marcha y la respuesta honesta suele ser un intervalo. Agentes de Copilot creados por empleados, modelos dentro de productos SaaS, modelos de ciencia de datos de hace cinco años, algún piloto que llegó a producción sin hacer ruido. Todo programa de gobernanza de IA descubre tarde o temprano que no puede gobernar lo que no ha contado. SAS puso a disposición su respuesta a ese problema el 5 de octubre.

Qué ha lanzado SAS

SAS AI Navigator, presentado en SAS Innovate en abril, ya está disponible como SaaS en Microsoft Marketplace. Según el comunicado de SAS:

• elabora un inventario de casos de uso de IA y de los modelos, agentes y herramientas que los sustentan, desarrollados internamente o comprados a terceros, incluidos LLM, agentes, modelos de código abierto y soluciones de SAS;
• permite alinear los casos de uso con normativas y políticas internas, en todo el ciclo de vida, desde la experimentación hasta la retirada;
• puede gobernar casos de uso basados en agentes o modelos como Claude o Microsoft Copilot;
• los paquetes de políticas de los socios Protiviti y Asenion aportan preguntas y clasificaciones de riesgo listas para aplicar;
• los clientes disponen de seis meses de acceso gratuito.

El comunicado no describe ninguna integración técnica con Microsoft más allá de la distribución en Marketplace y la alianza entre ambas compañías, así que no dé por hecho que Navigator lee por sí solo su entorno de Microsoft 365 o Azure. El lenguaje de SAS es prudente: Navigator ayuda a “alinear” casos de uso con la normativa. No promete el cumplimiento, y el comprador tampoco debería leerlo así.

Por qué el caso de uso es la unidad correcta

Casi todos los registros de agentes cuentan agentes; casi todos los registros de modelos cuentan modelos. SAS ancla el inventario en el caso de uso, el punto donde la IA toca una decisión de negocio. Es en ese nivel donde existe el riesgo. El mismo modelo puede redactar textos de marketing y filtrar candidaturas de empleo; solo uno de esos usos es de alto riesgo. Un registro que solo conoce el modelo no distingue entre ambos.

Esto encaja de forma directa con el Reglamento europeo de IA, que clasifica el riesgo por uso y no por tecnología. Aunque las obligaciones para sistemas de alto riesgo se aplazaron a diciembre de 2027, las prácticas prohibidas y la obligación de alfabetización en IA se aplican desde febrero de 2025, y nadie puede demostrar que no usa un sistema prohibido sin saber qué sistemas usa. Complementa, sin sustituirlos, los planos de control por agente que analizamos en nuestro análisis de los planos de control por encima de los proveedores.

Qué debe contener cada registro

1. Responsable de negocio y proceso
2. Modelos, agentes y proveedores detrás
3. Categorías de datos que lee y escribe
4. Nivel de riesgo y políticas aplicables
5. Evidencia de que los controles funcionan
6. Estado y próxima revisión

Hechos que se recogenCriterio que se documenta

La entrada es lo difícil. El inventario solo es tan completo como el camino por el que llegan los registros. Los formularios de autodeclaración se pierden justo los casos más importantes. Aliméntelo desde sistemas que ya lo saben: contratos de compras con cláusulas de IA, facturación de nube con endpoints de modelos, Microsoft Entra Agent ID para los agentes y los agentes de Copilot que crean los propios empleados. Y vincúlelo al registro de actividades de tratamiento del artículo 30 del RGPD: todo caso de uso que trate datos personales ya debería estar allí.

Los paquetes de políticas son criterio prestado. Los de Protiviti y Asenion ahorran meses de redacción de preguntas y niveles de riesgo. Aun así, son la lectura de otro sobre las normas. Los equipos jurídico y de riesgos deben adoptar cada paquete de forma explícita, ajustarlo y hacerlo suyo. La responsabilidad no viene incluida con el contenido.

Mapear no es evidencia. Vincular un caso de uso a un requisito deja constancia de que el requisito aplica. El cumplimiento exige pruebas de que el control funciona: resultados de pruebas, registros de revisión, monitorización. Como defendimos en nuestro análisis de los controles que generan evidencia, un control sin evidencia es una promesa.

Qué hacer ahora

1. Use el caso de uso como unidad del inventario, vinculado a los modelos y agentes que lo sustentan.
2. Alimente el inventario desde sistemas, no solo desde formularios: compras, facturación, identidad.
3. Conéctelo al registro de actividades de tratamiento y a su delegado de protección de datos.
4. Adopte los paquetes de políticas de forma deliberada, con un responsable en jurídico o riesgos.
5. Exija evidencia por control, no solo el mapeo a un requisito.
6. Planifique el séptimo mes: decida antes de que acabe el periodo gratuito dónde vivirá el inventario y cómo exportarlo.

En resumen

SAS AI Navigator recuerda que la gobernanza de la IA empieza por un problema de hoja de cálculo: saber qué existe. Anclar el inventario en el caso de uso es el diseño correcto. Solo recuerde que un requisito mapeado es una tarea pendiente, no un control terminado.