Índice
- AI TRiSM: ¿de qué hablamos exactamente?
- ¿Por qué los agentes de IA cambian la naturaleza del riesgo?
- Los controles de AI TRiSM, de la primera prueba al incidente
- Guía práctica para implementar AI TRiSM en seis pasos
- AI TRiSM, AI Act y RGPD: ¿cómo se relacionan?
- ¿Qué preguntas hacer a un proveedor de agentes de IA?
- Gobernar una IA significa decidir qué puede hacer cuando nadie la está supervisando
- FAQ sobre AI TRiSM
- Referencias
¿Qué ocurre cuando un agente de IA utiliza una fuente incorrecta, accede a un campo confidencial o ejecuta una acción que nadie puede revertir?
En una empresa, esta cuestión marca la diferencia entre una simple experimentación y un sistema realmente integrado en las operaciones. Mientras la IA genere un borrador que después revisa un empleado, el riesgo es relativamente limitado. Pero cuando interactúa directamente con un cliente o actúa dentro de una herramienta empresarial, una respuesta incorrecta puede convertirse en una cita mal registrada, la divulgación de información sensible o una promesa comercial imposible de cumplir.
AI TRiSM comienza precisamente en este punto. Su objetivo no es ralentizar los proyectos, sino hacer explícitas las reglas necesarias para implementarlos sin perder el control sobre los datos, las decisiones y las acciones.
AI TRiSM: ¿de qué hablamos exactamente?
AI TRiSM significa «AI Trust, Risk and Security Management», es decir, la gestión de la confianza, los riesgos y la seguridad de la inteligencia artificial. Este enfoque combina gobernanza, supervisión, validación y mecanismos de protección para que los sistemas de IA sean fiables, seguros y se mantengan dentro de su ámbito de uso previsto [1].
Abarca todo el sistema, no solo el modelo:
- los datos recibidos y consultados;
- las instrucciones proporcionadas al modelo;
- las bases documentales utilizadas;
- las aplicaciones y API conectadas;
- las acciones que puede ejecutar el agente;
- las reglas para transferir el caso a una persona;
- los registros necesarios para detectar y analizar un incidente.
Por tanto, AI TRiSM no es un chatbot, un agente de IA para ventas ni un software de ciberseguridad con IA. Es un enfoque que permite definir cómo deben seleccionarse, configurarse, probarse y supervisarse estos componentes.
Tampoco es una norma ni una obligación legal independiente. Implementar un programa de AI TRiSM no basta para demostrar que una empresa cumple con el RGPD o el AI Act. Este enfoque ayuda, más bien, a convertir los requisitos internos, legales o contractuales en controles aplicables.
Una metodología complementaria consiste en organizar la gestión de riesgos en torno a cuatro funciones: gobernar, identificar, medir y gestionar. La gobernanza está presente durante todo el ciclo de vida, mientras que los riesgos se reevalúan periódicamente teniendo en cuenta el contexto real de uso [2].
El nivel de control adecuado depende de la autonomía del agente
Imaginemos tres agentes que utilizan el mismo modelo de lenguaje:
| Agente de IA | Acceso y autonomía | Posible consecuencia de un error |
|---|---|---|
| Asistente de redacción interno | Genera un borrador sin acceder a datos de clientes | Un empleado debe corregir el texto |
| Agente de soporte | Consulta una base de conocimiento y responde directamente | El cliente recibe un procedimiento incorrecto |
| Agente comercial conectado al CRM | Consulta una ficha, califica al prospecto y agenda una cita | Se expone un dato o se registra una acción incorrecta |
El modelo puede ser el mismo, pero el nivel de riesgo no. Por eso, el análisis debe centrarse en el sistema completo y sus posibles efectos, no solo en la calidad media de sus respuestas.
¿Por qué los agentes de IA cambian la naturaleza del riesgo?
Un asistente IA conversacional clásico responde. Un asistente IA o agente IA puede, según su configuración, seleccionar una herramienta, buscar información, modificar un sistema externo y completar una tarea en varios pasos.
Esta capacidad de actuar introduce cuatro puntos de atención.
Una respuesta convincente puede seguir siendo incorrecta
Imaginemos un agente encargado de responder preguntas sobre suscripciones. Un cliente le pregunta si una cancelación da derecho a un reembolso. El agente genera una respuesta precisa y convincente, pero utiliza una versión antigua de las condiciones contractuales.
La respuesta parece correcta. El problema puede no detectarse hasta que el cliente presenta una reclamación.
Entre los riesgos asociados a la IA generativa se encuentran la generación de información incorrecta presentada con seguridad, las vulneraciones de la confidencialidad, los problemas de integridad de la información y las amenazas para la seguridad de los sistemas [3].
Por tanto, el control no consiste únicamente en comprobar si la respuesta «parece correcta». También hay que verificar:
- la fuente utilizada;
- su fecha de actualización;
- el respeto del ámbito autorizado;
- el comportamiento del agente cuando no existe una respuesta fiable.
Un acceso útil puede convertirse en un acceso excesivo
Un agente que agenda una cita necesita el nombre del cliente, sus datos de contacto y la disponibilidad relevante. No necesariamente necesita consultar todo su historial, sus reclamaciones anteriores o las notas privadas de los comerciales.
Cada conector amplía el ámbito de actuación del sistema. Un acceso al CRM diseñado para agilizar una conversación puede exponer más información de la necesaria para ese caso de uso.
Cuando un tratamiento implica datos personales, su finalidad debe ser determinada, explícita y legítima. Los datos utilizados también deben ser adecuados, pertinentes y limitados a lo necesario para alcanzar ese objetivo [4].
Una respuesta incorrecta puede desencadenar una acción incorrecta
Una alucinación incluida en un borrador puede corregirse antes de enviarlo. Una alucinación que desencadena una acción produce inmediatamente un efecto operativo.
Por ejemplo, un agente podría:
- crear un ticket en la categoría incorrecta;
- concertar una cita con un interlocutor no disponible;
- modificar el estado de una oportunidad;
- enviar un resumen con información incorrecta;
- transferir la conversación al departamento equivocado.
Por eso, conviene distinguir entre acciones reversibles y acciones sensibles. Añadir una nota interna y aprobar un reembolso no requieren el mismo nivel de autorización.
El sistema puede cambiar aunque el caso de uso no cambie
Aunque el agente mantenga el mismo nombre y la misma interfaz, su comportamiento puede cambiar después de:
- una actualización del modelo;
- una modificación de las instrucciones;
- la incorporación de una nueva fuente documental;
- la activación de una nueva integración;
- un cambio en los permisos de acceso;
- una actualización realizada por un proveedor.
Un test satisfactorio durante el lanzamiento no garantiza el rendimiento futuro. AI TRiSM considera la puesta en producción como el inicio de la supervisión, no como el final del proyecto.
Los controles de AI TRiSM, de la primera prueba al incidente
Una demostración satisfactoria demuestra que el agente puede gestionar algunos escenarios preparados. No muestra cómo reaccionará ante una petición ambigua, una fuente contradictoria o un intento de eludir sus controles.
Las evaluaciones deben realizarse antes del despliegue y repetirse periódicamente durante la operación [2].
Antes del despliegue: definir los límites de actuación
El equipo debe documentar primero:
- la función exacta del agente;
- los usuarios a los que afecta;
- las fuentes que puede consultar;
- los datos que puede recopilar;
- las herramientas a las que puede conectarse;
- las acciones que puede ejecutar;
- las situaciones en las que debe transferir el caso a una persona.
Para un agente de gestión de citas, el alcance podría ser: identificar el motivo de la consulta, consultar los horarios disponibles, recopilar los datos necesarios y confirmar la reserva. Asesorar al cliente sobre una cláusula contractual o modificar su suscripción quedaría fuera de su alcance.
Los tests deben cubrir tanto los escenarios habituales como las solicitudes incompletas, contradictorias o maliciosas.
Durante la interacción: controlar entradas, salidas y acciones
La supervisión en producción no consiste en revisar manualmente cada conversación. Su objetivo es detectar los eventos que requieren intervención, como:
- intentos de obtener información no autorizada;
- respuestas sin una fuente suficientemente fiable;
- una sucesión inusual de llamadas a herramientas;
- un volumen anormal de acciones;
- un aumento de la tasa de errores o transferencias;
- la aparición de datos sensibles en una respuesta;
- intentos de eludir una instrucción o un control.
Las medidas de protección también deben cubrir la arquitectura en la que opera el agente. Las recomendaciones de seguridad aplicables a los sistemas de IA generativa destacan la importancia de integrar medidas de seguridad desde el diseño hasta el uso en producción [5].
Después de una evolución: repetir los escenarios críticos
Una nueva base documental puede mejorar la cobertura de las respuestas y, al mismo tiempo, introducir contradicciones. Una nueva integración puede ampliar las capacidades del servicio, pero también dar acceso a datos adicionales.
Por eso, cada cambio significativo debe activar una serie de pruebas proporcional a su impacto:
- ¿Siguen funcionando los escenarios críticos del negocio?
- ¿Se mantienen las restricciones anteriores?
- ¿El agente utiliza la versión correcta de los documentos?
- ¿Se conservan las reglas de transferencia a una persona?
- ¿Son estrictamente necesarios los nuevos permisos?
Un entorno de pruebas controlado, procedimientos de integración adecuados y el registro de las salidas facilitan la detección de errores antes y después del despliegue [6].
En caso de incidente: entender antes de reactivar
Suspender temporalmente un agente no es suficiente. La empresa debe poder reconstruir la secuencia de acontecimientos:
- ¿Qué solicitud se realizó?
- ¿Qué fuentes y datos consultó el agente?
- ¿Qué versión del modelo y de las instrucciones estaba utilizando?
- ¿Qué herramientas se ejecutaron?
- ¿Qué acción se llevó a cabo?
- ¿Qué control debería haberla detenido?
- ¿Quién puede autorizar la reactivación?
Sin esta información, la corrección puede limitarse a ocultar el síntoma sin solucionar la causa.
| Riesgo | Control esperado | Responsable principal | Evidencia que debe conservarse |
|---|---|---|---|
| Respuesta incorrecta | Pruebas de negocio y control de las fuentes | Responsable del negocio | Resultado de la prueba y versión documental |
| Acceso excesivo | Permisos limitados según la finalidad | Responsable técnico | Matriz de permisos |
| Datos sensibles en una respuesta | Filtrado y regla de bloqueo | Responsable de seguridad o DPO, según el riesgo | Registro del evento |
| Acción de alto impacto | Validación humana previa | Responsable del negocio | Historial de aprobación |
| Cambio de comportamiento | Pruebas de regresión | Equipo de producto o IA | Informe previo a producción |
| Incidente con un cliente | Procedimiento de escalado y parada | Responsable designado | Cronología y decisión de cierre |
Guía práctica para implementar AI TRiSM en seis pasos
El despliegue no comienza con la compra de una plataforma de gobernanza. Comienza con seis decisiones que la empresa debe poder explicar y justificar.
1. Inventariar los agentes, modelos y conectores
El inventario debe incluir tanto las herramientas desplegadas oficialmente como las funciones de IA integradas en los programas que ya utiliza la empresa.
Para cada sistema, registra:
- el proveedor y la versión;
- la finalidad;
- el responsable del negocio;
- los datos tratados;
- las herramientas conectadas;
- las acciones posibles;
- los usuarios afectados;
- la fecha de la última evaluación.
Un inventario limitado al nombre de los proveedores no permite comprender el riesgo. Dos equipos pueden utilizar el mismo servicio con permisos y consecuencias muy diferentes.
2. Clasificar los casos de uso según su impacto
La clasificación puede basarse en cuatro preguntas:
- ¿El agente interactúa directamente con un cliente?
- ¿Maneja datos personales o confidenciales?
- ¿Puede modificar un sistema o ejecutar una acción?
- ¿Puede un error producir una consecuencia difícil de corregir?
Un agente que reformula una nota interna pertenece a una categoría diferente de uno que califica un prospecto, reserva una cita y actualiza el CRM.
Esta clasificación determina la intensidad de las pruebas, la supervisión y la validación humana. Permite evitar controles desproporcionados para usos de bajo riesgo y, al mismo tiempo, prestar mayor atención a los agentes con más autonomía.
3. Asignar responsabilidades, no solo tareas
La responsabilidad no puede quedar repartida sin un responsable claro entre los equipos de negocio, TI, legal y el proveedor.
El responsable del negocio define la finalidad y el nivel de servicio aceptable. El responsable técnico controla las integraciones, los permisos y el funcionamiento. Los especialistas en seguridad, datos o cumplimiento intervienen según el nivel de riesgo.
Debe existir además una persona responsable de responder a tres preguntas: ¿quién puede suspender el agente?, ¿quién valida la corrección? y ¿quién autoriza su reactivación?
4. Limitar los datos y acciones accesibles
Aplica el principio de mínimo privilegio al agente, igual que harías con un empleado:
- acceso únicamente a los campos necesarios;
- permisos de solo lectura cuando no sea imprescindible modificar información;
- separación entre los entornos de prueba y producción;
- periodos de conservación adecuados;
- validación humana para las acciones sensibles;
- identificadores independientes que permitan atribuir las acciones al agente.
Empezar con un ámbito reducido también facilita el análisis de los resultados. La autonomía puede ampliarse cuando los controles hayan demostrado su eficacia.
5. Probar escenarios reales e intentos de elusión
Un conjunto de pruebas útil no incluye únicamente las preguntas más frecuentes. También debe contemplar:
- una solicitud fuera de alcance;
- una instrucción ambigua;
- dos documentos contradictorios;
- un dato que falta;
- un intento de obtener información confidencial;
- una petición formulada con enfado o ironía;
- la indisponibilidad de una herramienta conectada;
- una situación que requiera una transferencia inmediata.
Para cada escenario, define el resultado esperado. «El agente debe responder correctamente» no es un criterio medible. «El agente rechaza proporcionar el dato solicitado, explica su limitación y transfiere la solicitud» sí lo es.
6. Supervisar indicadores que permitan tomar decisiones
Los cuadros de mando demasiado generales pueden ocultar los problemas relevantes. Es preferible seguir indicadores vinculados a una acción concreta:
- tasa de respuestas incorrectas en una muestra controlada;
- tasa de transferencia a una persona;
- tasa de resolución sin intervención manual;
- número de acciones bloqueadas;
- número de accesos rechazados;
- tasa de éxito de los escenarios críticos;
- número de incidentes por versión del sistema;
- tiempo medio de detección y resolución.
Una tasa elevada de transferencias no es necesariamente negativa. Puede indicar que el agente respeta correctamente sus límites. Los indicadores deben interpretarse siempre en función del nivel de riesgo y de la promesa realizada al cliente.
AI TRiSM, AI Act y RGPD: ¿cómo se relacionan?
El 2 de agosto de 2026 entraron en vigor nuevas obligaciones de transparencia previstas en el artículo 50 del AI Act para determinados sistemas de IA [7].
En el caso de los sistemas diseñados para interactuar directamente con personas, estas deben ser informadas, en principio, de que están interactuando con una IA, salvo cuando esto resulte evidente por el contexto [8].
Este requisito afecta directamente a determinados agentes conversacionales o de voz. Sin embargo, es solo una parte del análisis.
El RGPD sigue aplicándose cuando el agente trata datos personales. En ese caso, es necesario analizar aspectos como la finalidad del tratamiento, la base jurídica, los datos necesarios, el periodo de conservación, la información proporcionada a las personas y el ejercicio de sus derechos. Nuestra guía sobre IA y RGPD permite profundizar en este aspecto.
AI TRiSM ayuda a convertir estos requisitos en controles operativos: gestión de accesos, validación, registro de actividad, supervisión o procedimientos de gestión de incidentes. No sustituye al análisis jurídico.
Del mismo modo, no todos los agentes de IA se clasifican automáticamente como sistemas de alto riesgo. La clasificación depende de su finalidad, su contexto de uso y el papel que desempeña la organización.
¿Qué preguntas hacer a un proveedor de agentes de IA?
Durante una demostración, un agente suele responder a las solicitudes previstas. La verdadera evaluación comienza cuando se le retira información, se le presentan dos fuentes contradictorias o se le pide ejecutar una acción no autorizada.
Antes de elegir una solución, puedes plantearte las siguientes preguntas:
- ¿Qué datos se envían al modelo y dónde se procesan?
- ¿Se utilizan estos datos para entrenar o mejorar otros modelos?
- ¿Es posible limitar los accesos por agente y caso de uso?
- ¿Las acciones del agente quedan asociadas a una identidad propia en los registros?
- ¿Qué versiones del modelo, las instrucciones y las fuentes pueden rastrearse?
- ¿Cómo se puede probar una modificación antes de pasarla a producción?
- ¿Qué controles funcionan durante la conversación?
- ¿Puede una acción sensible requerir validación humana?
- ¿Cómo transfiere el agente una interacción junto con su contexto?
- ¿Cómo se pueden recuperar los registros necesarios en caso de incidente?
- ¿Es posible suspender rápidamente un agente sin desactivar todo el servicio?
- ¿Qué responsabilidades corresponden al proveedor y cuáles siguen siendo responsabilidad del cliente?
El caso de un agente de voz conectado a herramientas empresariales
Un agente de voz ilustra bien la necesidad de analizar toda la cadena. No se limita a generar una respuesta: escucha una solicitud, recopila información, consulta eventualmente una herramienta y puede desencadenar una serie de acciones.
Estas capacidades hacen especialmente relevantes varias cuestiones:
- ¿Qué información está autorizado a recopilar el agente?
- ¿Qué campos puede añadir a la ficha del cliente?
- ¿En qué situaciones debe detener el proceso?
- ¿Qué acciones requieren la confirmación del interlocutor?
- ¿En qué momento debe retomar la conversación un asesor?
- ¿Qué contexto debe transmitirse durante la transferencia?
AIRO es un ejemplo de agente que debe estar sujeto a estos controles, pero no constituye por sí mismo una solución de AI TRiSM. La gobernanza sigue siendo una responsabilidad compartida entre el proveedor, la empresa que configura el agente y los equipos que utilizan sus resultados.
Gobernar una IA significa decidir qué puede hacer cuando nadie la está supervisando
Un agente de IA fiable no es simplemente aquel que supera una demostración. Es un sistema cuyos responsables conocen sus fuentes, accesos, límites y acciones, incluso después de una actualización o cuando una interacción se sale del escenario previsto.
AI TRiSM proporciona una estructura para mantener este control. Vincula cada riesgo con un control, cada control con un responsable y cada decisión con una evidencia. Esta lógica permite evitar dos extremos: bloquear todos los proyectos por precaución o descubrir sus límites cuando un cliente ya ha sufrido las consecuencias.
Para empezar, elige un único agente de IA y documenta cuatro elementos: qué puede leer, qué puede decir, qué puede hacer y qué situaciones deben provocar una transferencia a una persona. Esto ya proporciona una primera base para construir un sistema de AI TRiSM.
FAQ sobre AI TRiSM
¿Cuál es la diferencia entre AI TRiSM y la gobernanza de la IA?
La gobernanza define las responsabilidades, políticas y decisiones. AI TRiSM añade los mecanismos de evaluación, supervisión y seguridad necesarios para aplicar estas reglas durante todo el ciclo de vida.
¿AI TRiSM es una norma o una certificación?
No. Es un enfoque para gestionar la confianza, los riesgos y la seguridad de la IA. Una empresa no cumple automáticamente una normativa por declarar que aplica AI TRiSM.
¿Hay que aplicar AI TRiSM a un proyecto piloto?
Sí, pero de forma proporcional. Un piloto debería contar, como mínimo, con una finalidad definida, un responsable, un ámbito de datos, criterios de éxito y una condición de parada.
¿Quién debe liderar AI TRiSM?
El liderazgo debe involucrar a un responsable de negocio y a un responsable técnico. El CISO o responsable de seguridad, el DPO, el equipo jurídico, los equipos de datos o cumplimiento deben intervenir en función de los riesgos del caso de uso.
¿Debe una persona validar todas las acciones de un agente de IA?
No necesariamente. La validación humana debe centrarse en las acciones sensibles, difíciles de revertir o susceptibles de tener consecuencias importantes. Las acciones sencillas y reversibles pueden automatizarse con una supervisión adecuada.
Referencias
- [1] https://www.gartner.com/en/articles/ai-governance-trism
- [2] https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
- [3] https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
- [4] https://www.cnil.fr/fr/definir-une-finalite-0
- [5] https://messervices.cyber.gouv.fr/guides/recommandations-de-securite-pour-un-systeme-dia-generative
- [6] https://www.aepd.es/sites/default/files/2020-02/adecuacion-rgpd-ia.pdf
- [7] https://digital-strategy.ec.europa.eu/en/library/guidelines-transparency-obligations-providers-and-deployers-ai-systems
- [8] https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?qid=1788662127473&uri=CELEX%3A02024R1689-20260727
Publicado el 7 Octubre 2026.