¿Qué es el riesgo de la IA?
Gobernanza, riesgo y aseguramiento
El riesgo de la IA es la posibilidad de que un sistema de IA cause daño, pérdidas o incertidumbre inaceptable para una empresa, sus clientes, su personal o la sociedad en general. Abarca fallos técnicos, problemas de datos y privacidad, amenazas cibernéticas, exposición legal, preocupaciones sobre sesgos y equidad, daño reputacional, desperdicio financiero y uso indebido por parte de la organización. La IA requiere atención especial porque su comportamiento puede ser probabilístico, dependiente de los datos, difícil de explicar, rápido de escalar y, en algunos casos, capaz de actuar con un control humano limitado.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
La mayoría de los líderes empresariales ya comprenden el riesgo tecnológico. Los servidores fallan, el software tiene errores, los proyectos se retrasan y los proveedores decepcionan. La IA incluye todo eso, pero añade una capa diferente de incertidumbre. Muchos sistemas de IA no siguen un conjunto fijo de reglas desde la entrada hasta la respuesta. Infieren patrones a partir de datos, producen respuestas variables y pueden comportarse de manera convincente aun siendo incorrectos.
Esto importa porque la calidad del sistema está ligada a la calidad de los datos, la forma en que se plantea la tarea, los prompts o instrucciones que recibe y el entorno en el que se utiliza. Un modelo que parece sólido en una demostración puede rendir mal en el trabajo real, especialmente cuando las personas hacen preguntas inusuales, cuando los datos cambian o cuando el sistema tiene acceso a herramientas y procesos empresariales en tiempo real.
El riesgo de la IA también es más sociotécnico que el riesgo del software convencional. El daño suele manifestarse a través de la interacción entre el comportamiento del modelo, el juicio humano, las políticas, los incentivos y el diseño de procesos. Un modelo defectuoso por sí solo puede no causar grandes problemas. El mismo modelo integrado en procesos de selección de personal, concesión de créditos, asesoramiento a clientes, clasificación de incidentes de seguridad o automatización basada en agentes puede generar efectos legales, comerciales y humanos muy rápidamente.
Por qué importa
La IA está pasando de los experimentos a la atención al cliente, la redacción, la búsqueda, el análisis, la automatización de flujos de trabajo, el apoyo a la toma de decisiones y la ejecución de tareas por agentes. Esto significa que el riesgo de la IA ya no es solo una preocupación para los equipos de datos o los innovadores. Se ha convertido en un asunto de liderazgo porque afecta a los ingresos, los costes, el cumplimiento normativo, la resiliencia y la confianza.
Gestionada de forma deficiente, la IA puede producir asesoramiento erróneo, exponer información sensible, automatizar decisiones incorrectas, profundizar sesgos, crear vulnerabilidades de seguridad o encadenar a una empresa a herramientas costosas en las que el personal no confía. Gestionada correctamente, la gestión del riesgo logra lo contrario. Aclara dónde es apropiada la IA, dónde se necesitan controles más estrictos y dónde una empresa debe detenerse, rediseñar o mantener a una persona al mando. Una buena gestión del riesgo de la IA no es un freno a la adopción. Es lo que hace que la adopción sea creíble y repetible.
Cómo funciona
Las principales categorías de riesgo de la IA
Riesgo operativo y de rendimiento
El riesgo operativo y de rendimiento es el riesgo de que el sistema simplemente no funcione lo suficientemente bien para la tarea que se le ha asignado. Esto incluye baja precisión, respuestas inconsistentes, alucinaciones, calibración deficiente, comportamiento frágil ante casos extremos, recuperación poco fiable, resúmenes débiles y deriva del modelo tras el despliegue. En el aprendizaje automático clásico, la deriva ocurre cuando el mundo cambia y los patrones aprendidos por el modelo ya no se corresponden con la realidad. En los sistemas generativos, los problemas de fiabilidad también pueden provenir de cambios en los prompts, errores de recuperación, límites de la ventana de contexto o cambios realizados por el proveedor en un modelo alojado.
Para los líderes empresariales, el punto clave es que el rendimiento de la IA no es una puntuación única. Un sistema puede parecer excelente en promedio y aun así fallar gravemente en los casos que más importan, como clientes vulnerables, contratos inusuales, eventos críticos para la seguridad o patrones de fraude de baja frecuencia. El riesgo operativo implica, por tanto, preguntarse si el sistema es suficientemente bueno para esta tarea específica, bajo este nivel específico de escrutinio, con umbrales de fallo claros y rutas alternativas cuando algo sale mal.
Riesgo de datos
El riesgo de datos subyace a gran parte del riesgo de la IA, porque los datos determinan lo que el sistema aprende, lo que puede ver y cómo se comporta en producción. Los problemas incluyen datos inexactos, desactualizados, incompletos, no representativos o mal etiquetados. En la IA generativa, el riesgo de datos también abarca una selección deficiente de fuentes para la recuperación, permisos de documentos inadecuados, procedencia ambigua y la reutilización silenciosa de material personal o confidencial en lugares donde no debería aparecer.
El sesgo suele comenzar aquí. Si los datos utilizados para entrenar, ajustar o alimentar un sistema reflejan desigualdades históricas, muestreos sesgados o variables proxy no examinadas, el sistema puede reproducir o amplificar esos patrones. Los riesgos de privacidad y confidencialidad también residen aquí. Los equipos pueden recopilar más datos personales de los necesarios, conservarlos demasiado tiempo, mezclar datos para distintos fines o permitir que proveedores externos retengan prompts y archivos. En el extremo más hostil, el envenenamiento de datos es la manipulación deliberada de los datos de entrenamiento, ajuste fino o recuperación para que el modelo se comporte de forma incorrecta, se vuelva sesgado u oculte una puerta trasera.
Riesgo de seguridad
El riesgo de seguridad de la IA ha pasado de ser una preocupación de nicho a una preocupación generalizada. La inyección de prompts es el ejemplo más claro. Un atacante puede elaborar texto que lleve a un modelo a ignorar instrucciones previas, divulgar información o hacer un uso indebido de las herramientas conectadas. Cuando la instrucción hostil está oculta en contenido recuperado, correos electrónicos, páginas web, PDFs o documentos, en lugar de en el prompt visible del usuario, el peligro aumenta porque el ataque puede propagarse a través de un flujo de trabajo aparentemente normal.
Otros riesgos de seguridad incluyen ataques adversariales que manipulan el comportamiento del modelo, robo de modelos, extracción de información sensible de entrenamiento, archivos de modelos inseguros, conjuntos de datos de terceros envenenados, compromiso de dependencias y cadena de suministro, permisos débiles de plugins o herramientas, y uso indebido de APIs a escala. La lección práctica es que el modelo es solo una parte de la superficie de ataque. El sistema circundante, incluidos prompts, capa de recuperación, alojamiento del modelo, conectores, identidades, secretos, registros y permisos de usuario, es generalmente donde se crea o previene el daño empresarial.
Riesgo legal y regulatorio
El riesgo legal y regulatorio va más allá de "¿podríamos ser multados?". Incluye si el diseño del sistema, el uso de datos, la lógica de automatización y el modo de despliegue se ajustan a las leyes y obligaciones que ya se aplican a la empresa. La ley de protección de datos, la confidencialidad, el derecho laboral, la legislación sobre igualdad, la protección del consumidor, las normas sectoriales, la legislación sobre seguridad de productos, la propiedad intelectual, las obligaciones de conservación de registros, los términos contractuales y los estándares profesionales pueden ser todos relevantes al mismo tiempo.
Los datos de entrenamiento y los derechos de autor siguen siendo áreas especialmente activas. Las preguntas sobre el acceso lícito a material protegido por derechos de autor, las excepciones para la minería de textos y datos, las licencias, las opciones de exclusión y la responsabilidad por el contenido generado siguen evolucionando en distintas jurisdicciones. El EU AI Act añade una nueva capa mediante un régimen basado en riesgos con obligaciones que dependen del uso y el tipo de sistema. El enfoque actual del Reino Unido sigue siendo más basado en principios y liderado por los reguladores, por lo que las empresas a menudo necesitan cumplir a través de la legislación existente en lugar de esperar a una única norma específica para la IA. Para muchas organizaciones, la consecuencia operativa es sencilla: la revisión legal debe realizarse antes de la adquisición y antes del despliegue, no después de que surja un problema público.
Riesgo ético y social
El riesgo ético y social se refiere a si el sistema trata a las personas de manera justa, respeta la dignidad y la autonomía, y puede ser comprendido y cuestionado en los contextos en que se utiliza. El sesgo y la discriminación están en el centro, pero la categoría es más amplia. También abarca la opacidad, la escasa explicabilidad, el diseño inaccesible, la manipulación, la vigilancia, la exclusión de grupos minoritarios y la eliminación del juicio humano significativo donde ese juicio sigue siendo importante.
Esta es una de las razones por las que el riesgo de la IA no puede reducirse únicamente a métricas del modelo. Una herramienta puede ser estadísticamente sólida y aun así éticamente débil si se utiliza para el propósito equivocado, se aplica a la población incorrecta o se integra en un proceso que no ofrece a las personas afectadas ninguna vía para cuestionarlo o corregirlo. La supervisión humana importa aquí, pero solo si esa supervisión es real. Un revisor nominal que no puede ver suficiente información, no comprende los límites del modelo o no tiene autoridad para intervenir no es un control. Es teatro.
Riesgo reputacional y de confianza
El riesgo reputacional y de confianza suele ser el primer riesgo que perciben los líderes, incluso cuando la causa raíz se encuentra en otro lugar. Los clientes raramente separan un error del modelo de la empresa que lo desplegó. El personal no distingue entre un control débil del proveedor y un fallo de gobernanza interna. Si un chatbot de IA inventa una política, si una herramienta de selección de personal parece injusta o si un empleado filtra material sensible a un sistema no autorizado, el daño reputacional recae sobre la organización.
El riesgo de confianza no es solo externo. La confianza interna importa igual. Si los empleados no creen que las herramientas son seguras, justas o útiles, la adopción se estanca o se vuelve encubierta. Si los líderes exageran lo que la IA puede hacer, la credibilidad cae cuando la realidad los alcanza. Las empresas suelen descubrir demasiado tarde que la confianza es acumulativa y frágil. Se construye mediante límites de uso claros, transparencia sobre las limitaciones, juicio humano consistente y corrección visible cuando algo falla. Sin eso, cada nuevo despliegue genera más fricción que el anterior.
Riesgo financiero y estratégico
El riesgo financiero y estratégico es el riesgo de que la IA consuma dinero, atención directiva o flexibilidad estratégica sin justificar su coste. Esto incluye casos de negocio inflados, costes ocultos de inferencia e integración, adquisiciones deficientes, duplicación de herramientas, adopción débil, experimentación no gestionada, apego a proyectos fallidos por el coste hundido y dependencia de proveedores que limita el poder de negociación o las opciones de salida en el futuro.
También existe el coste de oportunidad. Algunas organizaciones pasan demasiado tiempo debatiendo futuros abstractos de la IA mientras los competidores mejoran el servicio, la velocidad y la eficiencia en áreas acotadas y de menor riesgo. Otras se lanzan a programas costosos sin un modelo operativo claro y descubren que la verdadera limitación era el diseño de procesos, la disciplina de datos o la capacidad del personal, no la capacidad del modelo. El riesgo estratégico de la IA, por tanto, actúa en ambas direcciones. Es el riesgo de hacer lo incorrecto, escalar lo incorrecto o esperar tanto tiempo que lo correcto se vuelva más difícil y costoso.
Riesgo humano y organizativo
El riesgo humano y organizativo se subestima con frecuencia porque no parece técnico. Sin embargo, muchos fallos de la IA comienzan en los incentivos, la propiedad y el comportamiento. Los equipos pueden depender en exceso de respuestas fluidas, aceptar borradores débiles sin verificarlos, usar cuentas personales o herramientas no autorizadas, o asumir que comprar a un proveedor grande transfiere la responsabilidad a otro lugar. El personal también puede perder habilidades si el razonamiento crítico, la escritura, el análisis o el juicio se delegan repetidamente sin salvaguardas deliberadas.
La IA en la sombra forma parte de este panorama. Cuando las personas sienten presión para avanzar rápidamente pero no disponen de herramientas, políticas ni apoyo aprobados, suelen utilizar lo que resulte más fácil. Esto puede generar un manejo fragmentado de los datos, registros inconsistentes, exposición legal y versiones contradictorias de la verdad. El riesgo organizativo también incluye el fracaso del cambio. Un sistema técnicamente sólido puede fallar igualmente si la empresa no ha definido quién es su responsable, cómo encaja en los controles existentes, para qué debe confiar en él el personal y cuándo debe ignorarlo o anularlo.
Riesgo de sistemas agénticos y autónomos
Los sistemas agénticos y autónomos aumentan el perfil de riesgo porque no solo generan contenido. Pueden planificar, elegir herramientas, llamar a otros sistemas, escribir o modificar registros, enviar mensajes, desencadenar transacciones y seguir trabajando en múltiples pasos con una intervención humana reducida. Esto crea una versión más aguda de los riesgos conocidos e introduce nuevos en torno al alcance, la acción y el control.
Un chatbot ordinario que inventa una respuesta puede hacer perder tiempo. Un agente con acceso de escritura a finanzas, CRM, adquisiciones, correo electrónico o repositorios de código puede convertir el mismo error subyacente en un incidente grave. Los riesgos principales son el acceso con privilegios excesivos, las acciones no intencionadas, los errores en cascada entre sistemas, la inyección de prompts a través del contenido recuperado, los bucles descontrolados, el gasto no autorizado, la débil auditabilidad y la pérdida de capacidad humana para comprender o detener lo que hace el sistema. Por esta razón, la IA agéntica debe tratarse como una clase de control diferente. Necesita un alcance más restringido, puertas de aprobación más estrictas, acceso con mínimos privilegios, registros más completos, una propiedad más clara y mecanismos de desconexión más rápidos que un asistente de solo lectura.
Cómo interactúan y se amplifican los riesgos
Cadenas de fallos compuestos
Los riesgos de la IA raramente se presentan de uno en uno. Se propagan por el sistema en cadenas. Un defecto en los datos se convierte en un problema de rendimiento. Ese problema de rendimiento se convierte en un problema de equidad porque los errores afectan más a un grupo que a otro. Las quejas lo convierten entonces en un problema reputacional, mientras que los mismos hechos generan exposición legal y regulatoria. Si los líderes tratan cada categoría de forma aislada, pasan por alto la naturaleza compuesta del fallo.
La IA generativa hace esto aún más evidente, porque el comportamiento del modelo, la calidad de la recuperación, el comportamiento del usuario, el diseño de la interfaz y los permisos de las herramientas interactúan constantemente. Un modelo puede ser técnicamente capaz y aun así producir daños graves porque el proceso circundante fomenta la sobreconfianza, oculta la incertidumbre o permite que un paso débil desencadene una acción en el mundo real.
Un equipo de ventas despliega un modelo de puntuación de clientes potenciales entrenado con un historial de CRM desordenado. Los datos infrarepresentan a los clientes más pequeños y reflejan hábitos de venta antiguos. El modelo empieza a dirigir el esfuerzo hacia operaciones que se parecen al pasado. Las previsiones de ingresos se sesgan, algunos segmentos de clientes reciben un servicio de menor calidad y las quejas aumentan. Lo que comenzó como un riesgo de calidad de datos se ha convertido ahora en un riesgo operativo, de equidad, comercial y reputacional.
A un agente de atención al cliente se le permite leer correos electrónicos y aprobar pequeños reembolsos. Un mensaje hostil incluye texto oculto diseñado para redirigir el razonamiento del agente. El agente sigue la instrucción maliciosa, expone texto de política interna y emite reembolsos que no debería autorizar. Esa secuencia pasa del riesgo de seguridad a la pérdida financiera, las preocupaciones de confidencialidad, la respuesta a incidentes y el deterioro de la confianza en la automatización.
Por qué falla el tratamiento aislado
El tratamiento aislado falla por otra razón. Los controles en un área pueden desplazar el riesgo a otra. Más datos pueden mejorar la precisión pero empeorar la exposición a la privacidad. Barreras más estrictas pueden reducir el uso indebido pero hacer el sistema menos útil, llevando al personal de vuelta a herramientas en la sombra. Una verificación humana intensiva puede reducir el riesgo legal pero eliminar el argumento económico de la automatización. Una buena gobernanza no pretende que estas tensiones desaparezcan. Las hace explícitas, asigna responsables y establece compromisos en línea con el apetito de riesgo y la prioridad empresarial.
Ejemplos
Una empresa de selección de personal que usa IA para resumir currículums
Una empresa de selección de personal de tamaño mediano quiere utilizar un asistente de IA para resumir currículums y redactar notas breves sobre candidatos para los consultores. Sobre el papel, la tarea parece administrativa. En realidad, toca la equidad, el empleo, la privacidad y la reputación. Si el asistente sobreenfatiza determinadas universidades, empleadores, indicios de edad o lagunas en el historial laboral, puede inclinar a los consultores hacia una selección sesgada aunque no haya ninguna clasificación automática visible.
Un enfoque proporcionado consiste en mantener el sistema en un rol de apoyo, eliminar la puntuación directa de candidatos, probar los resúmenes con una muestra representativa, eliminar atributos personales innecesarios en la medida de lo posible y proporcionar a los consultores orientación explícita de que la herramienta no debe utilizarse como base definitiva para las decisiones de idoneidad. Añadir una DPIA si el uso de datos personales es de alto riesgo, documentar el uso previsto y las exclusiones, y muestrear los resultados regularmente para detectar sesgos e inexactitudes.
Un minorista que despliega un agente de atención al cliente para reembolsos
Un minorista en línea quiere un agente de IA para responder preguntas sobre entregas y gestionar reembolsos de bajo valor. El argumento comercial es sólido, pero el riesgo cambia en el momento en que el sistema puede actuar. Una inyección de prompt oculta dentro de un mensaje o una página recuperada podría desviar al agente de su curso. El modelo también puede inventar políticas, revelar lógica interna o aplicar excepciones de forma inconsistente. Eso crea riesgo financiero, de seguridad, de consumidor y de confianza al mismo tiempo.
El diseño más seguro es el de alcance restringido. Dar al agente acceso de lectura al estado de los pedidos y una función de reembolso con un límite estricto, no un control amplio de la cuenta. Requerir aprobación humana por encima de un umbral. Usar acciones en lista de permitidos, límites de velocidad, registros sólidos y monitorización diaria de patrones de reembolso inusuales o deriva de políticas. Probar con prompts adversariales antes del lanzamiento y tras cambios importantes en el modelo. Mantener un mecanismo de desconexión y una ruta alternativa hacia la atención humana.
Una empresa de servicios profesionales que añade un asistente de conocimiento interno
Un despacho de abogados, una firma de contabilidad o una consultora introduce un asistente basado en recuperación sobre documentos internos y trabajo con clientes. El personal valora la velocidad, pero el riesgo real es la confidencialidad y la sobreconfianza. Si los permisos son incorrectos, el asistente puede mostrar material que el usuario no debería ver. Si la fuente recuperada es débil o está desactualizada, la respuesta puede sonar autorizada siendo incorrecta. Si el personal empieza a pegar material de clientes en herramientas externas fuera del entorno aprobado, el riesgo de IA en la sombra aparece de inmediato.
Un conjunto de controles razonable comienza con límites de acceso que reflejen los permisos de los documentos, más orientación sobre qué archivos pueden y no pueden cargarse. Las respuestas deben mostrar referencias de fuentes internamente para que el usuario pueda verificarlas. El asesoramiento dirigido al exterior debe requerir la aprobación de una persona. La empresa debe registrar el uso, revisar las consultas de alto riesgo, formar al personal en confidencialidad y disciplina de verificación, y exigir una revisión de adquisición antes de conectar cualquier nuevo complemento de IA a datos de clientes.
Un fabricante que utiliza mantenimiento predictivo
Un fabricante despliega un modelo para predecir fallos de equipos a partir de datos de sensores. No es IA generativa, pero el patrón de riesgo sigue siendo distintivamente propio de la IA. Si el modelo deriva a medida que las máquinas envejecen o cambian los patrones de mantenimiento, los falsos negativos pueden generar tiempos de inactividad o exposición a riesgos de seguridad. Si el flujo de datos pierde o distorsiona las lecturas de los sensores, los operadores pueden confiar en una previsión débil. Si el proveedor actualiza el modelo sin un aviso claro, el rendimiento de la planta puede cambiar antes de que nadie entienda por qué.
La respuesta adecuada es tratar el modelo como un control operativo, no como una novedad del panel de control. Definir el proceso de respaldo humano, hacer seguimiento de los falsos positivos y falsos negativos, comparar el modelo con el juicio de los ingenieros de mantenimiento, monitorizar la deriva en tiempo real y exigir una gestión del cambio controlada para las actualizaciones del proveedor o de las funcionalidades. Cuando la seguridad está en juego, el modelo debe informar la priorización del mantenimiento, no reemplazar silenciosamente el juicio de ingeniería.
Malentendidos frecuentes
El riesgo de la IA tiene que ver principalmente con escenarios existenciales lejanos. En la mayoría de las empresas, los riesgos inmediatos son ordinarios y concretos: asesoramiento incorrecto, controles débiles, fallos de privacidad, trato injusto, integración insegura y errores costosos.
Si la herramienta es solo interna, el riesgo es bajo. Los sistemas internos también pueden filtrar datos, desorientar al personal, distorsionar decisiones y crear problemas de cumplimiento, especialmente cuando manejan información personal, confidencial o regulada.
Tener un humano en el bucle hace que la IA sea automáticamente segura. Un revisor humano solo ayuda si comprende la tarea, puede ver suficiente evidencia, tiene tiempo para juzgar correctamente y está facultado para anular el sistema.
Comprar a un proveedor importante transfiere el riesgo. Los proveedores pueden reducir el esfuerzo de construcción, pero quien despliega sigue siendo responsable de muchos de los efectos legales, de proceso y operativos del uso.
Si una demostración parece impresionante, el riesgo en producción es manejable. Las demostraciones raramente muestran casos extremos, prompts hostiles, problemas de permisos o los cambios de comportamiento que ocurren una vez que el personal empieza a depender de una herramienta a diario.
El cumplimiento normativo y la buena gobernanza son lo mismo. El cumplimiento importa, pero una empresa puede desplegar igualmente mal un sistema legalmente delimitado si carece de una propiedad clara, monitorización, control de cambios o supervisión real.
El modelo es el sistema completo. En la práctica, gran parte del riesgo reside alrededor del modelo: flujos de datos, prompts, recuperación, herramientas, permisos, contratos, comportamiento del personal y diseño de procesos.
Riesgos y límites
Cómo se evalúa el riesgo de la IA
Comenzar por el caso de uso y el contexto
Una buena evaluación comienza por la tarea que realizará el sistema, no por la etiqueta de marketing del modelo. Los líderes deben preguntarse: ¿Qué decisión o acción está influyendo esta IA? ¿Quién podría verse afectado? ¿Qué datos necesita? ¿Cómo sería un fallo? ¿Qué tan grave sería ese fallo? ¿Puede una persona detectarlo y corregirlo a tiempo? ¿El sistema solo asesora o puede actuar? ¿Es interno, orientado al cliente o parte de un proceso regulado?
Este enfoque evita dos errores comunes. El primero es tratar toda la IA como igualmente arriesgada. El segundo es asumir que el mismo modelo tiene el mismo riesgo en todas partes. Un modelo de resumen utilizado para redactar notas internas de reuniones no conlleva el mismo riesgo que el modelo idéntico utilizado para generar sugerencias de triaje médico o clasificar candidatos a un puesto de trabajo.
Usar un ciclo estructurado de Gobernar, Mapear, Medir, Gestionar
Una estructura práctica es el NIST AI Risk Management Framework. Gobernar es la capa fundacional. Abarca política, roles, responsabilidad, apetito de riesgo, formación, escalada y vínculos con la gobernanza existente. Mapear es donde la empresa define el contexto, el uso previsto, las partes interesadas, las fuentes de datos, los límites del sistema, las dependencias y los posibles daños. Medir es donde la organización prueba lo que puede probar, elige métricas, realiza evaluaciones y documenta lo que aún no puede medirse de forma fiable. Gestionar es donde los líderes deciden qué hacer con el riesgo, incluyendo mitigación, transferencia, aceptación, pausa, rediseño o desmantelamiento, y donde mantienen la monitorización del rendimiento en tiempo real.
ISO/IEC 23894 complementa bien este enfoque. Trata la gestión del riesgo de la IA como algo que debe integrarse en el trabajo de riesgo organizativo existente, en lugar de ejecutarse como una isla separada. Para muchas empresas, esa es la mentalidad correcta. La IA debe conectarse con la gobernanza establecida para la seguridad de la información, la gestión de proveedores, la revisión legal, la auditoría interna, la resiliencia operativa y la continuidad del negocio.
Evaluar la materialidad, no solo la calidad del modelo
La evaluación debe reflejar más que si el modelo es "preciso". Los líderes necesitan una visión de la materialidad. Las dimensiones útiles incluyen la gravedad del daño, la probabilidad, el número de personas afectadas, la velocidad del impacto, la detectabilidad, la reversibilidad y el grado de control humano. Un error de baja probabilidad puede seguir siendo de alto riesgo si afecta a la seguridad del paciente, los derechos laborales, el acceso a servicios esenciales o la integridad de los registros financieros.
La cuantificación ayuda cuando es creíble, pero el riesgo de la IA a menudo resiste las estimaciones de probabilidad precisas, especialmente al inicio del despliegue. Eso es normal. Conviene usar una combinación de evidencia de pruebas, análisis de escenarios, juicio experto, hallazgos de equipos de ataque, datos piloto y métricas operativas. Cuando la medición es débil, la respuesta no es ignorar el riesgo. Es reconocer que la incertidumbre en sí misma forma parte del riesgo y actuar con más cautela.
Conectar la evaluación de la IA con la gestión de riesgos empresariales y las evaluaciones de impacto
El riesgo de la IA debe alimentar el proceso más amplio de gestión de riesgos empresariales de la organización. Los usos materiales de la IA deben figurar en el registro de riesgos, con responsables designados, controles acordados, fechas de revisión y umbrales claros para la escalada a la alta dirección. Adquisiciones, legal, seguridad, privacidad, RRHH y operaciones deben poder ver dónde se utiliza la IA y qué controles se aplican.
Cuando se manejan datos personales, también puede ser necesaria una evaluación de impacto sobre la protección de datos. En muchos despliegues de IA, lo será. Una DPIA se centra específicamente en los riesgos para los derechos y libertades de las personas derivados del tratamiento de datos personales. Eso la hace esencial, pero no suficiente por sí sola. Debe tratarse como un componente de la evaluación más amplia del riesgo de la IA, junto con la revisión de seguridad, el análisis de equidad, la diligencia debida con proveedores y cualquier trabajo de impacto sectorial o de igualdad que sea aplicable. Para las organizaciones más pequeñas, el método más proporcionado suele ser un único paquete de evaluación integrado en lugar de un conjunto de formularios desconectados.
Priorizar con decisiones claras
El objetivo de la evaluación no es el papeleo. Es la toma de decisiones. Cada uso material de la IA debe concluir con una de un número reducido de decisiones: proceder, proceder con condiciones, solo piloto, rediseñar o detener. Las condiciones pueden incluir un alcance más restringido, una revisión humana más sólida, pruebas adicionales, mejores controles de datos o un cambio en los términos del proveedor. El riesgo residual debe ser visible, no estar oculto. Los altos directivos no necesitan todos los detalles técnicos, pero sí necesitan una declaración clara de qué podría salir mal, qué controles están en vigor y qué desencadenaría una reevaluación.
Mitigación y controles
Supervisión humana y derechos de decisión
La supervisión humana funciona cuando está diseñada como un control operativo, no como un eslogan. El revisor debe saber para qué sirve el sistema, cuáles son sus límites, cuándo desconfiar de él y qué autoridad tiene para intervenir. En trabajos de redacción de bajo riesgo, esto puede significar una revisión simple antes del uso externo. En entornos de mayor riesgo, puede significar aprobación dual, campos de explicación obligatorios o una regla que establezca que la IA puede recomendar pero nunca decidir. Cuanto más grave sea el posible daño, más significativo debe ser el control humano.
Una buena supervisión también separa los roles. La persona que se beneficia de la velocidad no siempre es la más adecuada para cuestionar el modelo. Para decisiones importantes, conviene considerar si el mismo empleado debe tanto operar la herramienta como aprobar su resultado. Cuando se involucran sistemas agénticos, hay que definir quién autoriza el acceso, quién monitoriza la actividad, quién gestiona los incidentes y quién puede detener el sistema de inmediato.
Pruebas y evaluación antes del lanzamiento
Antes del despliegue, hay que probar el sistema frente al trabajo real que realizará. Usar ejemplos representativos, casos extremos y casos de fallo, no solo prompts ideales y datos pulidos. Comparar el sistema con el rendimiento humano, métodos basados en reglas o análisis más simples donde sea relevante. Registrar los límites de error aceptables, los umbrales de confianza y las condiciones bajo las cuales la herramienta no debe utilizarse.
La evaluación debe incluir más que la precisión en la tarea. Verificar si hay problemas de equidad entre los grupos relevantes, estabilidad ante variaciones menores en la entrada, comportamiento bajo presión, manejo de datos y si el sistema sigue siendo útil cuando se aplican barreras de seguridad. Si un caso de uso depende de la recuperación, evaluar la calidad de la recuperación por separado de la calidad de la generación. Si depende del uso de herramientas, probar los permisos y los efectos secundarios por separado de la calidad del lenguaje.
Red-teaming y pruebas adversariales
El red-teaming es una prueba de desafío estructurada. Busca formas en que el sistema puede ser manipulado, eludido, utilizado de forma indebida o llevado más allá de sus límites previstos. Para un chatbot, esto puede significar intentos de jailbreak, inyección de prompts, contenido abusivo, suplantación de identidad o pruebas de exfiltración de datos. Para un agente de flujo de trabajo, puede significar probar si las entradas hostiles pueden desencadenar acciones no autorizadas, si los límites pueden eludirse y cómo se comporta el sistema cuando las herramientas fallan o devuelven datos contradictorios.
El red-teaming debe ser proporcionado y repetido. La necesidad es mayor cuando el sistema está orientado al cliente, tiene alto volumen, es relevante para la seguridad o está conectado a herramientas en tiempo real. También es mayor tras cambios significativos, como una actualización del modelo, un nuevo conector, permisos más amplios o la expansión a un nuevo grupo de usuarios.
Barreras de seguridad, control de acceso y arquitectura segura
Muchos daños de la IA pueden reducirse cambiando la arquitectura en lugar de intentar que el modelo en sí sea perfecto. Colocar controles basados en reglas alrededor del modelo. Limitar los datos que puede recuperar. Restringir las herramientas que puede invocar. Usar listas de permitidos en lugar de acciones abiertas, aplicar umbrales para pagos o cambios de registros, y mantener las herramientas de alto impacto detrás de puertas de aprobación humana. Para entornos sensibles, aislar el modelo de los sistemas críticos a menos que exista una necesidad empresarial clara.
El control de acceso importa especialmente con la IA agéntica. Usar mínimos privilegios, credenciales de corta duración y una separación sólida entre las capacidades de lectura, escritura y administración. Tratar los modelos de terceros, los plugins, los paquetes y las fuentes de datos públicas como dependencias de la cadena de suministro que requieren escrutinio. Un modelo con acceso amplio y contención deficiente no es una función de productividad. Es un incidente esperando un detonante.
Monitorización, observabilidad y gestión de la deriva
El control de la IA no se detiene en el lanzamiento. Los sistemas necesitan monitorización en tiempo real de la calidad, la fiabilidad, el uso indebido, la deriva, el comportamiento inusual y los comentarios de los usuarios. Esto generalmente implica registrar prompts, contexto clave, resultados, llamadas a herramientas, eventos de seguridad, anulaciones e incidentes, con controles de privacidad y seguridad sobre esos registros. Muestrear los resultados regularmente. Vigilar los patrones de error cambiantes, no solo las puntuaciones promedio. Hacer seguimiento de los casi-fallos, porque suelen ser la primera señal de un fallo mayor.
La deriva del modelo merece atención explícita. Los cambios en el comportamiento de los clientes, la combinación de productos, el lenguaje, la regulación o los datos de origen pueden erosionar silenciosamente el rendimiento. Los modelos fundacionales alojados también pueden cambiar porque el proveedor los actualiza. Si un cambio es material, el sistema puede necesitar nuevas pruebas, nueva aprobación, un uso más restringido o su retirada.
Documentación, trazabilidad y evidencia de garantía
La documentación es un control porque hace visibles los límites y auditables las decisiones. Un paquete de documentación sólido puede incluir el uso previsto, el uso excluido, el contexto de entrenamiento y evaluación, las métricas clave, las limitaciones conocidas, las fuentes de datos, los registros de aprobación, los registros de cambios, el diseño de la supervisión humana y las rutas de incidentes. Las fichas de modelo y artefactos similares son útiles porque obligan al equipo a declarar para qué es bueno el modelo, cómo fue probado y dónde no debe confiarse en él.
Aquí es también donde comienza la garantía de la IA. La garantía convierte las pruebas, la documentación, la monitorización y la revisión en evidencia en la que otras personas pueden confiar, ya sea una junta directiva, un cliente, un auditor o un regulador. Una organización de tamaño mediano no necesita una burocracia pesada para cada piloto, pero sí necesita suficiente calidad en los artefactos para que otra persona, seis meses después, pueda entender qué fue aprobado, sobre qué base y con qué salvaguardas.
Diligencia debida con proveedores, respuesta a incidentes y política
La IA de terceros puede reducir el riesgo de construcción, pero no elimina el riesgo de despliegue. Conviene preguntar a los proveedores cómo gestionan la seguridad, el control de acceso, la retención de datos, los subencargados, la gobernanza de los datos de entrenamiento, la notificación de incidentes, las actualizaciones del modelo y el alojamiento regional. Hay que entender qué dice el contrato sobre confidencialidad, responsabilidad, propiedad intelectual, derechos de auditoría y cambios en el servicio. Si la herramienta se utilizará en un proceso regulado o con impacto humano, solicitar evidencia de pruebas y documentación clara en lugar de afirmaciones de marketing.
Conviene tener una ruta de incidentes específica para la IA antes de que algo salga mal. Saber quién investiga, quién puede suspender una herramienta o revocar los permisos de un agente, cómo se informa a los usuarios afectados, cuándo se involucra a los equipos legales o de privacidad y cómo se capturan las lecciones aprendidas. Respaldar esto con política y formación. El personal debe saber qué herramientas están aprobadas, qué datos pueden usar, qué nunca debe cargarse, cómo informar de problemas y cuándo el uso de la IA requiere una revisión adicional.
Gobernanza y regulación
La gestión del riesgo de la IA se enmarca dentro de la gobernanza de la IA
La gobernanza de la IA es el sistema de gestión en torno al uso de la IA. La gestión del riesgo es una de sus funciones principales, pero no la totalidad. La gobernanza establece políticas, propiedad, rutas de aprobación, inventarios, rutas de escalada, responsabilidades de monitorización, líneas de reporte y expectativas de garantía. En términos prácticos, la gobernanza responde preguntas como: ¿Quién puede aprobar un uso de la IA? ¿Qué evidencia se necesita? ¿Qué usos deben ir a legal, privacidad o seguridad? ¿Cómo se notifican los incidentes? ¿Con qué frecuencia se revisa un uso en producción?
Sin gobernanza, el trabajo de riesgo sigue siendo ad hoc. Un equipo prueba cuidadosamente mientras otro despliega una herramienta no revisada a través de adquisiciones o una pestaña del navegador. Una buena gobernanza crea consistencia y proporción. No significa que cada uso necesite un comité. Significa que cada uso tiene una ruta que se corresponde con su materialidad.
Cómo encaja ISO/IEC 42001
ISO/IEC 42001 es útil porque ofrece a las organizaciones una estructura de sistema de gestión para gobernar la IA en toda la empresa. Conviene pensarlo como el esqueleto organizativo más que como la prueba para un modelo concreto. Ayuda a las empresas a definir políticas, responsabilidades, controles del ciclo de vida, monitorización y mejora continua. ISO/IEC 23894 se sitúa más cerca de la mecánica de la gestión del riesgo de la IA en sí, ayudando a las organizaciones a identificar, analizar, tratar y monitorizar los riesgos específicos de la IA en contexto.
Para una organización de tamaño mediano, estas normas son más útiles como guías de diseño. Pueden evitar que la gobernanza sea improvisada y ayudar a alinear la IA con las disciplinas de estilo ISO existentes, como la seguridad de la información, la calidad o la gestión de la privacidad. No reemplazan el juicio, las normas sectoriales ni las pruebas de casos de uso, pero pueden hacer que los tres sean más fáciles de ejecutar de forma consistente.
El EU AI Act
El EU AI Act es el ejemplo más claro actualmente de regulación de la IA basada en riesgos con alcance comercial global. Importa no solo a las empresas con sede en la UE, sino a cualquier empresa que coloque determinados sistemas de IA en el mercado de la UE o cuyo uso de la IA afecte a usuarios, clientes o cadenas de suministro de la UE. La norma prohíbe directamente una clase reducida de prácticas inaceptables, impone requisitos detallados a los sistemas de alto riesgo, crea obligaciones de transparencia para determinados sistemas interactivos y de contenido sintético, y añade obligaciones separadas para los modelos de IA de uso general.
A día de hoy, las prácticas prohibidas y las obligaciones de alfabetización en IA ya son aplicables. Las obligaciones de transparencia para determinados sistemas se aplican a partir del 2 de agosto de 2026. El calendario de implementación actual de la Comisión sitúa las principales obligaciones de alto riesgo del Anexo III más adelante, con el amplio conjunto de casos de uso de alto riesgo programado para el 2 de diciembre de 2027 y algunos sistemas de IA integrados en productos regulados aún más tarde. Las empresas no deben interpretar el escalonamiento como permiso para esperar. La adquisición, el diseño, el mantenimiento de registros y los términos con proveedores a menudo necesitan cambiar mucho antes de las fechas de aplicabilidad formal.
Para los sistemas de alto riesgo, la carga de cumplimiento es sustancial. Se espera que los proveedores ejecuten una gestión documentada del riesgo, una gobernanza de datos adecuada, documentación técnica, registros, supervisión humana, controles de precisión, robustez y ciberseguridad, evaluación de la conformidad y monitorización poscomercialización. Los desplegadores tienen sus propias obligaciones en materia de uso, supervisión, monitorización y, en algunos casos, evaluación de impacto e información a las personas afectadas. La norma también añade obligaciones para los modelos de IA de uso general, incluidas medidas de documentación y cumplimiento relacionadas con los derechos de autor, con obligaciones adicionales para los modelos que presentan riesgo sistémico. Incluso las organizaciones que nunca construyen modelos sentirán estos requisitos a través de contratos, solicitudes de documentación y diligencia debida de clientes.
El enfoque del Reino Unido liderado por los reguladores
El Reino Unido está tomando un camino diferente. En lugar de una única ley horizontal de IA al estilo de la UE, ha optado por un enfoque basado en principios y liderado por los reguladores. Los principios fundamentales son seguridad, protección y robustez; transparencia y explicabilidad apropiadas; equidad; responsabilidad y gobernanza; y posibilidad de impugnación y reparación. La intención es que los reguladores existentes los apliquen dentro de sus competencias, en lugar de hacerlo a través de una nueva norma única para todo uso de la IA.
Para los líderes empresariales, el efecto práctico es que el riesgo de la IA en el Reino Unido a menudo se gestiona a través de las leyes y los reguladores que ya existen, no a través de un reglamento exclusivo para la IA. La protección de datos sigue siendo relevante. Las obligaciones de igualdad y empleo siguen siendo relevantes. La protección del consumidor, la conducta financiera, la seguridad de los productos, la regulación de dispositivos médicos, las obligaciones profesionales, el derecho contractual y la propiedad intelectual siguen siendo relevantes. En la práctica, esto significa identificar el conjunto de reguladores pertinentes para el sector, como privacidad, finanzas, competencia, salud o supervisión laboral, antes de escalar un caso de uso.
Los derechos de autor son un buen ejemplo. El debate político en torno al entrenamiento con obras protegidas sigue activo, y el gobierno ha declarado que aún no está listo para reformar la legislación sobre derechos de autor hasta estar convencido de que cualquier cambio cumpliría sus objetivos. Eso significa que la incertidumbre legal sigue siendo un riesgo empresarial real, especialmente para los proveedores y para los desplegadores que dependen en gran medida de las garantías de los proveedores.
Normas sectoriales, garantía y el panorama global práctico
En la práctica, muchas organizaciones se verán atraídas por varios regímenes a la vez. Una empresa del Reino Unido que atiende a clientes de la UE puede tener que considerar el EU AI Act. Una empresa que vende en sanidad, finanzas, selección de personal o servicios públicos puede enfrentarse a expectativas sectoriales más estrictas independientemente de dónde esté ubicada. Los clientes empresariales solicitan cada vez más a los proveedores evidencia sobre gobernanza, pruebas, privacidad, seguridad y gestión de incidentes antes de comprar. Esa presión en la adquisición ya está actuando como una forma de disciplina de mercado.
Por eso importa la garantía. Las juntas directivas, los clientes y los reguladores quieren cada vez más evidencia, no aspiraciones. Un marco de gobernanza de la IA creíble vincula, por tanto, la política con la evaluación documentada del riesgo, el diseño de controles, los registros de pruebas, los datos de monitorización, los registros de incidentes y la revisión periódica. La regulación eleva las apuestas, pero una buena gobernanza seguiría valiendo la pena sin ella, porque convierte la IA de una capacidad prometedora pero frágil en algo en lo que la organización puede confiar.
Qué hacer a continuación
Elaborar un inventario de IA. Listar todos los usos de IA activos, en fase piloto y propuestos, incluidas las herramientas de proveedores, las funcionalidades integradas y el probable uso en la sombra en los departamentos habituales.
Clasificar cada uso según su impacto y autonomía. Preguntar qué influye, a quién afecta, qué datos maneja y si solo asesora o puede actuar.
Designar un responsable para cada uso material. El responsable debe ser un líder empresarial, no solo un especialista técnico, y debe rendir cuentas de la revisión, los controles y la operación.
Crear una línea de base de controles mínimos. Para la mayoría de las organizaciones de tamaño mediano, esto implica una política de herramientas aprobadas, revisión de privacidad y seguridad, diligencia debida básica con proveedores, uso previsto documentado, normas de revisión humana y escalada de incidentes.
Usar un único paquete de evaluación integrado para los casos materiales. Combinar la revisión del riesgo de la IA con la DPIA, la revisión de seguridad y las verificaciones específicas del sector cuando sea necesario, en lugar de crear documentos desconectados.
Pilotar en áreas acotadas primero. Elegir tareas con valor claro, menor daño inherente y fácil reversión. Mantener el alcance restringido hasta que la empresa tenga evidencia de que tanto los controles como la herramienta se sostienen.
Monitorizar tras el lanzamiento. Establecer fechas de revisión, muestrear resultados, recoger comentarios de los usuarios, hacer seguimiento de la deriva o el uso indebido y definir los desencadenantes para la reaprobación cuando cambien los modelos, los permisos o los casos de uso.
Establecer informes a nivel de junta directiva que sean simples y útiles. Los altos directivos deben ver dónde se utiliza la IA, qué sistemas tienen alto impacto, qué incidentes o casi-fallos han aparecido y dónde se está aceptando el riesgo residual.
¿Tiene alguna pregunta o sugerencia, o desea saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿El riesgo de la IA solo es un problema si desarrollamos nuestros propios modelos?
No. Muchos de los mayores riesgos residen en la adquisición, la configuración, los permisos, el diseño del caso de uso y la operación en tiempo real. Una empresa que utiliza IA de terceros puede igualmente causar brechas de privacidad, asesoramiento incorrecto a clientes, decisiones injustas o incidentes de seguridad.
¿Quién debe ser responsable del riesgo de la IA internamente?
Cada uso material de la IA debe tener un responsable empresarial designado. Ese responsable debe trabajar con seguridad, privacidad, legal, adquisiciones, RRHH y operaciones según sea necesario. La coordinación a nivel empresarial suele recaer en un COO, CIO, CDO o un responsable de gobernanza, pero la propiedad del caso de uso debe mantenerse cerca del proceso empresarial.
¿Necesitamos una política formal de IA antes de probar nada?
Se necesita un conjunto mínimo de normas antes de que el personal empiece a usar herramientas con datos reales. Comenzar con el uso aceptable, los datos prohibidos, las rutas de aprobación, la revisión de proveedores y la escalada de incidentes. Ampliar hacia un conjunto de políticas más completo a medida que el uso de la IA se extienda.
¿Cuándo se necesita una DPIA para la IA?
A menudo cuando el tratamiento de datos personales puede crear un alto riesgo para los derechos y libertades de las personas. La elaboración de perfiles, las decisiones significativas, la monitorización a gran escala, los datos sensibles y la IA orientada al público pueden aumentar la probabilidad. Muchos usos materiales de la IA deben tratarse como candidatos a DPIA hasta que se demuestre lo contrario.
¿Cuál es la diferencia entre la gobernanza de la IA y la gestión del riesgo de la IA?
La gobernanza es el sistema general de política, propiedad, derechos de decisión, revisión, monitorización y garantía. La gestión del riesgo es la disciplina de identificar, evaluar, priorizar y tratar los riesgos específicos de la IA. La gestión del riesgo se enmarca dentro de la gobernanza.
¿Con qué frecuencia debemos reevaluar un sistema de IA en producción?
Según un calendario y ante cambios. Reevaluar tras actualizaciones del modelo, nuevos permisos, nuevas fuentes de datos, expansión hacia un uso de mayor impacto, incidentes, deriva, cambios de proveedor o actualizaciones legales relevantes. Una buena regla es que cualquier cambio material debe desencadenar al menos una revisión específica.
¿Los modelos de código abierto son automáticamente más arriesgados que los modelos cerrados?
No automáticamente. Los modelos de código abierto pueden ofrecer más control y flexibilidad, pero también pueden generar más carga en torno a la seguridad, los parches, el alojamiento y la revisión de la cadena de suministro. Los modelos cerrados pueden reducir parte del esfuerzo operativo al tiempo que aumentan la dependencia y los límites de visibilidad. La pregunta real es si la organización puede gobernar la opción que elige.
¿Qué documentación es suficiente para una organización de tamaño mediano?
La suficiente para explicar el propósito, los datos, el proveedor, los límites, las pruebas, las aprobaciones, la supervisión humana, la monitorización y las rutas de incidentes. Si una segunda persona no puede entender por qué existe el despliegue, qué puede hacer y qué salvaguardas se aplican, el registro es demasiado escaso.
¿Cuándo debe un líder rechazar un caso de uso de IA?
Cuando el daño podría ser grave y la empresa no puede explicar, monitorizar, acotar o controlar el sistema de forma suficiente. También hay que rechazarlo cuando la base legal es demasiado incierta, cuando el uso depende de una automatización no verificada en una decisión de alto impacto o cuando un método más sencillo puede realizar el trabajo de forma más segura.
¿Puede una empresa de tamaño mediano gestionar el riesgo de la IA sin una gran función de gobernanza?
Sí. El objetivo es la proporción, no la burocracia. Un inventario integrado, un modelo de clasificación sencillo, responsables designados, una línea de base de controles mínimos y pilotos cuidadosos llevarán a la mayoría de las organizaciones muy lejos si aplican esas disciplinas de forma consistente.
¿Por qué la IA agéntica requiere una precaución adicional?
Porque el mismo error del modelo puede desencadenar acciones en herramientas y sistemas. Una vez que una IA puede enviar correos electrónicos, modificar registros, mover dinero o llamar a software en nombre de la empresa, los errores de texto se convierten en eventos operativos. Los sistemas agénticos necesitan un alcance más restringido, acceso con mínimos privilegios, umbrales de aprobación, registros detallados y controles de parada inmediata.
Fuentes
AI RMF Core - AIRC - NIST AI Resource Center (National Institute of Standards and Technology). The structure of the NIST AI Risk Management Framework, especially the Govern, Map, Measure, and Manage functions and their use in assessment and prioritisation.
ISO/IEC 23894:2023 Information technology - Artificial intelligence - Guidance on risk management (ISO). The role of ISO/IEC 23894 as guidance on AI-specific risk management integrated into wider organisational risk practice.
ISO/IEC 42001:2023 Information technology - Artificial intelligence - Management system (ISO). The role of ISO/IEC 42001 as an organisation-wide management system standard for AI governance.
AI Act | Shaping Europe's digital future (European Commission). EU AI Act overview, governance structure, current implementation status, and timeline of applicability.
Navigating the AI Act | Shaping Europe's digital future (European Commission). High-risk AI system examples, transparency duties, provider and deployer obligations, conformity assessment, and the role of standards.
AI regulation: a pro-innovation approach (UK Government). The UK's principles-based and regulator-led approach to AI regulation.
Implementing the UK's AI regulatory principles: initial guidance for regulators (UK Government). The five UK AI regulatory principles and how they are meant to be interpreted by existing regulators.
What are the accountability and governance implications of AI? (Information Commissioner's Office). DPIAs, accountability, meaningful risk appetite, controller and processor issues, and the link between AI risk work and data protection law.
Guidelines for secure AI system development (National Cyber Security Centre). Lifecycle security controls across design, development, deployment, monitoring, logging, and incident management.
Thinking about the security of AI systems (National Cyber Security Centre). Prompt injection, data poisoning, system architecture, access controls, and the importance of treating AI as part of a wider security system.
Thinking carefully before adopting agentic AI (National Cyber Security Centre). The heightened risks of agentic AI, including over-privileged access, scope limits, human accountability, monitoring, and incident planning.
Report and impact assessment on Copyright and Artificial Intelligence (UK Government). The current UK policy position on copyright and AI training, ongoing uncertainty, and the lack of settled reform at the time of writing.