Hilo de referencia · Cyber AI: gobernanza, riesgos y casos de uso

Sobre la (1): para copilotos de productividad de uso interno normalmente NO caen en alto riesgo del Anexo III; el grueso de obligaciones son las de transparencia (art. 50) y la alfabetización en IA (art. 4). Ojo que la propuesta de Ómnibus sobre IA reformula el art. 4 y aplaza la mayoría de obligaciones de alto riesgo a agosto 2026/2027. Distinto es si lo usáis para scoring de empleados o decisiones que afecten a personas.

Para el shadow AI lo que mejor nos ha funcionado es DLP a nivel de navegador + una política clara de "datos que NUNCA van a un prompt" (PII de clientes, código propietario, datos de tarjeta). Bloquear del todo genera más shadow AI; mejor dar una alternativa aprobada con DPA firmado y registro de tratamiento bajo RGPD.

Desde red team: probad el OWASP Top 10 para LLM. Prompt injection (LLM01) e insecure output handling (LLM02) son los que más estamos explotando en ejercicios. Si exponéis un asistente con acceso a herramientas/funciones, tratad cada tool-call como una superficie de ataque: validad y limitad permisos como si fuera un usuario más.

Encaje regulatorio: nosotros (entidad financiera) tratamos los proveedores de GenAI como terceros TIC bajo DORA. Van al registro de información (art. 28), con due diligence y cláusulas de salida. Si el servicio soporta una función crítica, exigimos las cláusulas reforzadas. El AI Act se solapa pero no sustituye las obligaciones DORA de terceros.

Caso de uso real en SOC: usamos un LLM para triaje de alertas y redacción de informes de incidente. Reduce tiempo de cierre, pero NUNCA dejamos que ejecute acciones de contención automáticas; queda como copiloto con humano en el bucle. Lo mapeamos a RS.MA/RS.AN del NIST CSF 2.0 como mejora del proceso, no como control sustitutivo.

Para asegurar los propios modelos: gobernad el ciclo MLops como gobernáis el SDLC. Versionado de datasets, control de acceso al model registry, y evaluación de envenenamiento/extracción. Si entrenáis o hacéis fine-tuning con datos personales, documentad la base de legitimación (la propuesta de Ómnibus aclara el interés legítimo para entrenamiento de IA, pero hoy hay que justificarlo bien).

Un punto que se olvida: identidad de los agentes de IA. Si dais a un agente credenciales para actuar sobre sistemas, necesita su propia identidad no humana, con mínimo privilegio, rotación y trazabilidad. Lo estamos modelando como cuenta de servicio gobernada en IAM (PR.AA del CSF).

Gracias a todos, brutal el nivel. Resumen provisional para quien llegue nuevo: (a) copilotos internos = sobre todo transparencia + alfabetización IA; (b) shadow AI = DLP + alternativa aprobada con DPA; (c) proveedores GenAI = terceros TIC (DORA) + cláusulas IA; (d) seguridad técnica = OWASP LLM Top 10 + humano en el bucle; (e) identidad de agentes en IAM. Seguimos sumando casos.

Añadiría que, en entornos UE, yo no clasificaría de entrada un copiloto interno como alto riesgo por el mero hecho de ser IA; solo si entra en un caso del anexo III del AI Act o impacta de forma relevante en decisiones sobre personas. En la práctica, lo más eficaz contra shadow AI suele ser combinar CASB/DLP con política de uso y un servicio aprobado mejor que el público: si no das una alternativa usable, el usuario se la busca fuera.

Coincido con Diana: el copiloto interno no es “alto riesgo” per se; normalmente cae más en obligaciones de transparencia, logging y supervisión humana que en el régimen duro del anexo III del AI Act. Donde sí me he encontrado bastante fricción es en shadow AI, y ahí funciona mejor una combinación de DLP/CASB con bloqueo selectivo de dominios y una herramienta corporativa aprobada, porque si no el control se queda en papel.

Totalmente de acuerdo: el AI Act te lleva más a gobernanza y trazabilidad que a “alto riesgo” salvo encaje claro en anexo III, y en paralelo yo no perdería de vista GDPR art. 5 y 25 si el copiloto toca datos personales. En proveedores, además de las cláusulas TIC de DORA, estoy pidiendo ya anexos específicos sobre no-entrenamiento con nuestros datos, ubicación/subprocesadores y derecho de auditoría o evidencias de controles, porque ahí es donde luego suelen aparecer los sustos.