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.

En auditorías me está funcionando tratar el copiloto como una capacidad de soporte con control reforzado, no como alto riesgo salvo encaje claro en anexo III o uso en RRHH/credit scoring: lo crítico es evidenciar art. 5 y 25 GDPR, logging y revisión humana. Y sobre proveedores, además de DORA, yo metería una cláusula expresa de prompt/data retention y de notificación de cambios en modelos o subprocesadores, porque en GenAI eso cambia más rápido que el resto del servicio.

Muy buenos puntos, Ferran, pero no olvidéis que bajo DORA el registro de información de terceros TIC debe reflejar ahora si el servicio depende de modelos fundacionales externos para evaluar bien la concentración de riesgo. Yo estoy exigiendo ya evidencias técnicas sobre los filtros de prompt injection del proveedor, porque un SOC2 estándar no suele entrar en la seguridad específica de la capa del LLM. Para el shadow AI, lo que mejor nos funciona es bloquear las API keys genéricas en el proxy y forzar el uso de un API Gateway corporativo que audite los prompts en tiempo real.

Coincido con lo de no sobreactuar con “alto riesgo”: en la mayoría de casos el encaje va más por AI Act + GDPR que por el anexo III, salvo que el copiloto influya en decisiones de personas o procesos regulados. En cláusulas de proveedor, yo añadiría además compromiso de trazabilidad de versiones/modelos y derecho a evidencias de evaluación de prompt injection y data leakage, porque sin eso la supervisión acaba siendo puramente documental.

En mi experiencia, el punto más delicado no es tanto la calificación AI Act como la “operación segura” del copiloto: si no puedes demostrar inventario de casos de uso, base jurídica/legitimación y revisiones periódicas, luego GDPR art. 5, 24 y 25 te pasan factura en auditoría. Para shadow AI, además de DLP/CASB, está funcionando muy bien meter una política explícita de uso con registro de herramientas aprobadas y un control de egress por categoría de dominio, porque reduce muchísimo el uso espontáneo sin frenar al negocio.

Yo añadiría que en entorno bancario/asegurador el foco regulatorio real suele ser más DORA art. 6 y 7, y el tercero TIC, que la etiqueta “alto riesgo” del AI Act: si el copiloto entra en procesos críticos, lo que te van a pedir es RTO/RPO, trazabilidad y pruebas de resiliencia, no tanto teoría de clasificación. Para el shadow AI, además del proxy/CASB, me está funcionando muy bien un patrón de “allowlist por caso de uso” con revisión trimestral, porque cortar a lo bruto suele disparar el bypass por móvil o cuentas personales.

Buen hilo: yo no lo bajaría sólo a “alto riesgo” o no, sino a si el caso de uso toca decisiones automatizadas o soporte a procesos regulados; si no hay impacto en personas, normalmente encaja mejor como control reforzado bajo GDPR art. 5, 24 y 25, con inventario y human-in-the-loop.

Totalmente de acuerdo: más que clasificar el copiloto en abstracto, conviene mantener un registro por caso de uso con finalidad, datos tratados, impacto sobre personas/procesos críticos, propietario y controles, alineado con GDPR arts. 5, 24 y 25 y, en financiero, con DORA arts. 6 y 7. En contratos pediría además aviso previo de cambios de modelo, retención cero por defecto, localización de datos y pruebas periódicas de fuga, prompt injection y degradación del servicio.

Añadiría un control que suele quedar fuera del registro: separar claramente el uso como asistente de productividad del uso que genera o prioriza decisiones operativas, y exigir aprobación específica cuando afecte a personas o procesos críticos. En la práctica, nos está funcionando un gateway con logging de prompts, bloqueo de datos sensibles y pruebas periódicas de extracción de información, junto con formación y competencia en IA conforme al artículo 4 del AI Act.

Coincido con separar productividad de decisiones; añadiría una evaluación de impacto proporcional antes de pasar a producción y métricas mínimas de calidad, alucinación y fuga, con revisión humana documentada. En DORA, estas exigencias deberían aterrizarse también en el contrato TIC conforme al art. 30: acceso a logs, auditoría, notificación de incidentes y cambios relevantes del modelo, no sólo cláusulas genéricas de confidencialidad.