Cómo construir una plataforma de gobernanza de IA que funcione de forma continua
- La mayoría de las organizaciones tienen sistemas de IA en funcionamiento sin un solo equipo que se responsabilice del riesgo del ciclo de vida completo, lo que deja lagunas en la gestión del riesgo de la IA. Esta guía muestra a los líderes de GRC y seguridad cómo diseñar una gobernanza que sea continuamente activa, no atendida periódicamente.
- La pila de gobernanza de IA siempre activa consta de cinco capas: Datos, Modelo, Integración de sistemas, Monitoreo y Auditoría. Cada una de ellas debe estar en vivo, no solo documentada, para que la arquitectura pueda sostenerse.
- Antes de intentar obtener un presupuesto o apoyo operativo, compare cada sistema de IA con las cinco capas y evalúe honestamente qué controles están funcionando realmente; esa brecha es su punto de partida y su caso de negocio.
La mayoría de las organizaciones ya cuentan con, o están desarrollando, algún tipo de gobernanza de IA. Precisamente el 69.9%, según el informe CISO Pulse Check de Sprinto , publicado a principios de este año. Además, solo el 52.81% de los equipos de GRC (Gobierno, Riesgo y Cumplimiento) consideran la IA como una categoría independiente, y mucho menos garantizan una gestión continua del riesgo asociado a la IA.
Pero, ¿qué sucede con la gobernanza de la IA cuando su equipo de seguridad está revisando vulnerabilidades de día cero? ¿Cuando su equipo de cumplimiento está ocupado con la preparación de auditorías? ¿Cuando su proveedor de HRMS implementa una nueva función de IA integrada?
Ese es un problema de arquitectura.
Muchos equipos de GRC (y afines) están teniendo dificultades con la arquitectura de gobernanza de IA. Esto es lo que estamos escuchando:
Entonces, ¿cómo se puede construir una plataforma de gobernanza de IA que esté activa de forma continua en lugar de requerir atención periódica?
Esta guía está dirigida a profesionales de GRC que desean crear precisamente eso: una función operativa con controles que generen evidencia, detecten desviaciones y resistan el escrutinio, ya sea que una auditoría sea inminente o esté prevista para dentro de dos años.
Si su organización cuenta con sistemas de IA que interactúan con usuarios reales, influyen en decisiones empresariales reales o se conectan a datos internos en tiempo real, esta información le será útil. Algunos ejemplos son un modelo de detección de fraude, una herramienta de selección de currículos, asistentes virtuales para el personal y un chatbot que gestiona las consultas de los clientes. Por otro lado, si aún está evaluando o probando herramientas de IA sin que haya interacción directa con los clientes, sin que influyan en las decisiones empresariales y sin conexión a sistemas internos en tiempo real, utilice esta guía para diseñar la arquitectura antes de la implementación de los sistemas, en lugar de después.
Para empezar: comience con un marco de gobernanza de IA, pero elija sabiamente.
Antes de diseñar nada, aférrate a un estándar. No se trata de cumplir con un requisito formal; es una estrategia de credibilidad, un punto de referencia común para ti y las demás partes interesadas, y la base sobre la que se sustentará tu arquitectura de funcionamiento continuo.
Ley de IA de la UE : Seleccione esta opción si vende en los mercados europeos.
Marco de Gestión de Riesgos de IA del NIST : Esta es una buena opción si su principal necesidad es crear y poner en funcionamiento una función de gobernanza interna.
ISO 42001 : Si no tiene como objetivo los mercados europeos, pero necesita demostrar la gobernanza de la IA externamente a través de un sistema de gestión certificable, esta es una buena opción.
Ahora ya está listo para empezar a construir su pila de gobernanza de IA siempre activa.
Casi listo
Antes de poder gestionar la IA, debe asegurarse de que está realizando un seguimiento de todas las herramientas que entran en contacto con su infraestructura y su personal.
Si actualmente no puede enumerar todas las herramientas, modelos y casos de uso de IA que afectan a su infraestructura o a su personal, necesita esta información antes de poder embarcarse en una verdadera gobernanza de la IA.
Consejos para un inventario eficiente y sin lagunas:
- Utilice métodos de prueba tanto automatizados como manuales.
Los métodos automatizados como las pasarelas, CASB, MDM y el escaneo de código ofrecen cobertura a gran escala. Sin embargo, no detectan lo que no pueden ver: una clave API personal, un modelo oculto en una integración de terceros o una función de IA activada discretamente en una actualización de producto. El descubrimiento manual subsana estas deficiencias.
- Casos de uso del inventario, no solo herramientas.
Una sola herramienta puede gestionar cincuenta casos de uso, cada uno con su propio perfil de riesgo. Un copiloto de IA que redacta correos electrónicos internos plantea un problema de gobernanza distinto al de la misma herramienta que resume contratos con clientes o genera código de producción. Lo importante es qué hace la IA, para quién y en qué decisiones influye, no solo qué herramientas están licenciadas. Además, es fundamental etiquetar cada caso de uso según su origen: desarrollado internamente, adquirido y utilizado internamente, o desarrollado o implementado para clientes. Las obligaciones difieren sustancialmente entre estos tres casos, y confundirlos es uno de los errores más comunes en los programas de gobernanza de IA en sus primeras etapas.
- Estructúralo como una matriz, no como una lista.
Un proveedor puede gestionar múltiples casos de uso; un caso de uso puede depender de varios proveedores o modelos. Por consiguiente, el inventario debe mostrar qué casos de uso dependen de qué proveedores, modelos y fuentes de datos. Esta estructura es la que permite realizar una evaluación de riesgos a nivel de caso de uso.
- No lo consideres un ejercicio que se realiza una sola vez.
Constantemente se incorporan nuevas herramientas, se añaden funciones de forma silenciosa y los empleados encuentran maneras de eludir los canales autorizados. El proceso de descubrimiento debe ir de la mano con la infraestructura de gobernanza, no precederla.
– Implementar el descubrimiento automatizado en todos los canales disponibles.
– Crear un canal de autoinforme de baja fricción para que los empleados declaren las herramientas de IA y los casos de uso que el descubrimiento automatizado no puede alcanzar.
– Inventario a nivel de caso de uso, registrando qué hace la IA, para quién y en qué decisiones influye. Estructurar el inventario como una matriz que vincule los casos de uso con proveedores, modelos y fuentes de datos.
– Etiquete cada caso de uso por su origen: desarrollado internamente, comprado y utilizado internamente, o desarrollado/desplegado para clientes.
– Ejecutar el descubrimiento como una función continua, no como una auditoría única.
Ahora ya puedes empezar a planificar tu arquitectura de gobernanza de IA en el verdadero sentido de la palabra.
Imagina que tu sistema de gobernanza de IA tiene cinco capas, cada una de las cuales debe estar en funcionamiento antes de que la capa superior pueda sostenerse.
Capa 1: Gobernanza de datos de IA
Necesitas una gobernanza de datos de IA si algún sistema de IA en tu organización se entrena o se ajusta con datos internos, o si adquieres herramientas de IA sin saber en qué datos se basaron.
Todo sistema de IA se basa en datos. Antes de controlar el modelo, es necesario controlar su fuente de datos. Esto implica plantear preguntas que los profesionales de GRC (Gobierno, Riesgo y Cumplimiento) deberían conocer: ¿De dónde provienen estos datos? ¿Qué clasificación tienen? ¿Existe un registro de consentimiento? ¿Cómo se documenta el origen de los datos?
En un contexto de IA, los problemas de calidad de los datos pueden tener efectos retardados, a menudo invisibles. Un sesgo introducido durante la ingesta de datos puede no manifestarse como un fallo visible en la salida hasta meses después. Su arquitectura de gobernanza de IA debe contemplar herramientas que le permitan rastrear una salida problemática hasta sus datos de entrenamiento o ajuste fino en cualquier momento, no solo durante la implementación. Las herramientas necesarias para lograrlo dependen del tipo de modelo que utilice. Para los modelos preconfigurados, sus obligaciones se centran en los datos que se envían al modelo durante la inferencia. Para los modelos que entrene usted mismo, necesita una evaluación completa de los conjuntos de datos de entrenamiento, incluyendo su procedencia, consentimiento, representatividad y los sesgos que puedan introducir.
– Establecer fichas o hojas de datos para cada conjunto de datos de entrenamiento de IA. Deben describir su contenido, su origen y las exclusiones o transformaciones aplicadas.
– Defina los umbrales de calidad de los datos antes de que comience el desarrollo del modelo, no después de que surja un problema.
– Exigir la documentación de linaje como condición no negociable de cualquier contrato de adquisición de IA.
Capa 2: Gobernanza del modelo de IA
Necesitas una gobernanza de modelos de IA si algún sistema de IA toma decisiones o influye en ellas (sobre clientes, empleados, transacciones, riesgos o cualquier otro asunto importante) sin un proceso de validación formal antes o después de su implementación.
Una vez que se tiene visibilidad de los datos, se necesita un proceso para validar que los modelos se comporten según lo previsto y que sigan haciéndolo a medida que cambian las condiciones.
Aquí es donde muchas organizaciones no están preparadas en absoluto. Realizan una prueba de concepto, los resultados parecen razonables para el equipo que la encargó, y el modelo pasa a producción sin una validación formal.
La gobernanza de los modelos de IA cierra esa brecha al establecer qué se considera "bueno" antes de su implementación o adquisición, y al definir las condiciones bajo las cuales un modelo debe ser revalidado en lugar de asumir que sigue siendo bueno.
Sin embargo, antes de comenzar cualquier trabajo de validación, cada caso de uso declarado requiere su propia evaluación de riesgos. Esta debe abarcar preguntas como: ¿Cuál es el peor fallo posible para este caso de uso específico? ¿Quiénes se verían afectados si fallara? ¿Qué decisiones influiría? ¿Qué nivel de supervisión humana es apropiado? Las respuestas determinan el rigor de validación requerido, y este varía sustancialmente según el caso de uso, no solo según el modelo.
Consejo práctico: Los sistemas de IA con agentes requieren un escrutinio adicional en esta capa. Sus consideraciones de gobernanza de modelos son sustancialmente diferentes a las de los sistemas que generan resultados para revisión humana.
– Exigir una ficha de modelo para cada sistema de IA antes de su aprobación para la producción, en la que se muestren su propósito, las métricas de rendimiento, las limitaciones conocidas y el uso previsto.
– Realizar evaluaciones de sesgo y equidad alineadas con el contexto de riesgo específico del caso de uso (el mismo modelo puede ser totalmente apropiado para un caso de uso e introducir un riesgo de sesgo significativo en otro).
– Establecer parámetros de referencia de rendimiento en el momento de la implementación, con los que se pueda medir la desviación futura.
– Defina los desencadenantes de la revalidación, es decir, las condiciones bajo las cuales un modelo debe revisarse formalmente de nuevo, en lugar de asumir que sigue siendo apto para su propósito. Incorpore ciclos de revisión de proveedores en los contratos, no solo en la incorporación, sino a intervalos definidos a lo largo de la relación.
Capa 3: Gobernanza de la integración del sistema de IA
Necesitas una gobernanza de la integración de sistemas de IA si algún sistema de IA está conectado a datos en tiempo real, API internas u otros sistemas de software, en lugar de funcionar de forma aislada.
Los sistemas de IA se integran en arquitecturas técnicas más amplias, dependen de API y flujos de datos, e interactúan con otros sistemas de software de maneras que modifican sus propios riesgos de gobernanza.
La gobernanza de la integración de sistemas de IA consiste en comprender esas dependencias y los riesgos que conllevan, y mantener ese conocimiento actualizado a medida que evolucionan las arquitecturas. Un modelo que funciona bien en un conjunto de prueba puede comportarse de manera diferente cuando recibe entradas en formatos inesperados, cuando las canalizaciones de datos anteriores se retrasan o cuando se integra con un sistema que amplifica sus resultados sin revisión humana.
Si su organización está implementando o evaluando IA con agentes, la gobernanza de la integración del sistema debe definir explícitamente en qué punto del proceso un humano puede detener la ejecución, qué acciones pueden activar los agentes sin aprobación y el mecanismo de reversión en caso de que un agente genere un resultado perjudicial. Diseñar estos controles después de la implementación es considerablemente más difícil que diseñarlos antes.
Consejo práctico: el mapeo de dependencias de IA también debería incluir la continuidad del acceso al modelo: qué se rompe si un modelo, una API de proveedor, una región o una función deja de estar disponible, se restringe, se descontinúa o se modifica sustancialmente.
Esta capa requiere una estrecha colaboración con los equipos de arquitectura e ingeniería, mantenida mediante puntos de contacto regulares en lugar de una única revisión previa al lanzamiento.
– Mantener arquitecturas de sistema documentadas con componentes de IA identificados explícitamente, y actualizarlas a medida que el sistema cambie, no anualmente.
– Definir los requisitos de las pruebas de integración que abarquen tanto los modos de fallo como el funcionamiento normal.
– Asigne una responsabilidad clara a cada componente de IA dentro del sistema general. Incorpore mecanismos de supervisión humana (es decir, los puntos en los que un humano puede revisar, anular o detener los resultados generados por la IA) en la arquitectura desde el principio y pruébelos periódicamente para confirmar que realmente funcionan.
Definir un proceso explícito de desmantelamiento para los sistemas de IA que se desactiven, que abarque las obligaciones de retención de datos, la revocación del acceso y la preservación del registro de auditoría. Las obligaciones de gobernanza no terminan cuando se apaga un sistema.
– Mapear las dependencias de modelos y proveedores para cada flujo de trabajo habilitado para IA, incluidas las opciones de reserva en caso de que un modelo esté obsoleto, restringido, bloqueado por región o deje de estar disponible repentinamente.
Capa 4: Control y monitorización mediante IA
Es necesario un monitoreo continuo si algún sistema de IA es utilizado por usuarios reales, influye en decisiones reales o está conectado a datos en tiempo real, y nadie es formalmente responsable de detectar cuándo comienza a comportarse de manera diferente.
Esta es la capa que mantiene la pila siempre activa. Todo lo demás crea las condiciones para el uso seguro de la IA; esta capa es la que detecta cuándo esas condiciones dejan de cumplirse.
En este contexto, la monitorización abarca dos aspectos distintos: la monitorización del sistema, que incluye la configuración, el acceso y el estado, y la monitorización a nivel de transacción de cada interacción relacionada con la IA dentro de los límites de su organización: empleados que acceden a herramientas de IA a través de navegadores, llamadas a modelos mediante MCP y pasarelas de IA, aplicaciones de IA en dispositivos gestionados y personal que utiliza credenciales de la organización para iniciar sesión en herramientas de terceros que quizás nunca hayan sido revisadas formalmente. Ambas son necesarias y ninguna sustituye a la otra.
| A Estudio El análisis de 201 proveedores en 16 categorías muestra la gran cantidad de proveedores que requieren monitoreo en tiempo de ejecución en categorías de IA nativa y "no IA" (que han heredado el riesgo de la IA debido a integraciones y características de IA). |
Consejo práctico: La cuestión de la responsabilidad operativa es crucial aquí. Un monitoreo que nadie supervisa es irrelevante. Esta capa requiere un equipo designado con obligaciones de respuesta definidas, no solo acceso de lectura a un panel de control.
– Defina qué va a monitorizar y establezca los umbrales de detección antes de la puesta en marcha, no después del primer incidente.
– Implementar un sistema de monitorización del rendimiento que realice un seguimiento de las métricas de calidad de la salida a lo largo del tiempo, no solo del tiempo de actividad del sistema.
– Implementar la detección de anomalías en las distribuciones de entrada. Un cambio repentino en el tipo de consultas que recibe un modelo es una señal de alerta temprana.
– Distinga entre la supervisión del sistema y la supervisión a nivel de transacción de las salidas individuales de la IA y asegúrese de que ambas tengan responsables designados y umbrales definidos. Establezca un registro de incidentes para salidas inesperadas o dañinas con una ruta de escalamiento clara.
– Asigne propietarios con nombres específicos y acuerdos de nivel de servicio (SLA) de respuesta definidos, no solo visibilidad en el panel de control de monitorización.
Capa 5: Auditoría de IA y recopilación de evidencia
Si hoy en día le resultara difícil demostrar a un regulador o auditor que sus sistemas de IA están bajo control, necesita auditorías de IA y herramientas relacionadas para la recopilación de pruebas en su conjunto de herramientas de gobernanza de IA.
La capa superior es la que transforma un conjunto de controles en un programa de gobernanza sólido. La lógica es la misma que en las auditorías y en cualquier otro ámbito: es necesario poder demostrar, a posteriori, que los controles estaban implementados, que funcionaban eficazmente y que, cuando surgieron problemas, se identificaron y abordaron.
Lo que hace que esta capa sea fundamental para una infraestructura siempre activa es que la documentación debe reflejar el estado actual de los sistemas, no su estado en el momento de su lanzamiento. La IA evoluciona demasiado rápido para eso. La normativa, incluida la Ley de IA de la UE, es explícita al respecto: la documentación técnica para sistemas de alto riesgo debe abarcar el propósito previsto, las métricas de rendimiento, las prácticas de gobernanza de datos, la arquitectura de monitorización y los mecanismos de supervisión humana, y debe mantenerse actualizada. Pero incluso sin un requisito normativo, la documentación que describe un sistema tal como era hace dieciocho meses no constituye una gobernanza que genere confianza con los clientes o el consejo de administración. Es un registro histórico.
– Diseñe su arquitectura de documentación como infraestructura, no como un entregable del proyecto, sino como un registro vivo que se actualiza a medida que cambian los sistemas. Controle las versiones de toda la documentación de gobernanza para tener un historial rastreable de cómo han evolucionado los sistemas y los controles.
– Definir intervalos de revisión para toda la documentación y tratarlos como compromisos operativos, no como objetivos aspiracionales.
– Tratar la generación de evidencia como un subproducto del proceso de gobernanza. Si producir evidencia requiere un esfuerzo aparte, el proceso no está diseñado correctamente. Esto es una extensión de la Capa 4. Construir la recopilación de evidencia como un resultado continuo con un ciclo definido de verificación y corrección, no como un registro que se revisa retrospectivamente, sino como un proceso que revela deficiencias en tiempo real y realiza un seguimiento de su resolución.
Para saber en qué punto se encuentra actualmente su organización en cuanto a gobernanza de IA, dedique un minuto a utilizar la Calculadora de Madurez de Gobernanza de IA de Sprinto. Esta herramienta abarca las siete áreas más importantes —desde el inventario de IA y los controles con intervención humana hasta la visibilidad del ecosistema de proveedores y la transparencia externa— y le indica si su gobernanza está en desarrollo, en fase de madurez o avanzada. Pruébela ahora.
Kit de inicio para planificar su conjunto de herramientas de gobernanza de IA
1. Por dónde empezar
La arquitectura de gobernanza de IA siempre activa puede parecer ambiciosa para presentar a un equipo directivo que aún debate si la gobernanza de IA necesita siquiera una función propia. Analice cada sistema de IA actualmente en producción comparándolo con las cinco capas y determine con honestidad qué capas están activas y cuáles se dan por sentadas.
La mayoría de las organizaciones que realizan este ejercicio por primera vez descubren que las capas 4 y 5 están prácticamente ausentes. Si bien existe algún tipo de monitoreo, nadie es responsable de las decisiones sobre los umbrales ni del proceso de escalamiento. Existe documentación de la fase de adquisición o lanzamiento, pero no se ha actualizado desde entonces. Esa brecha entre los controles diseñados y los que realmente se implementan constituye su punto de partida y su justificación empresarial.
2. Abordar la conversación sobre la alineación
La clave para conseguir financiación y apoyo para una plataforma de gobernanza de IA siempre activa no reside en priorizar los marcos de trabajo ni las obligaciones de cumplimiento, aunque ambos aspectos son importantes. Se trata de hacer que el riesgo sea comprensible para quienes son responsables del mismo.
Ya se les está pidiendo a su junta directiva y a la alta gerencia que aprueben las implementaciones de IA. Lo que la mayoría aún no tiene es una respuesta clara a tres preguntas: ¿Cuáles de nuestros sistemas de IA podrían causarnos daños importantes si fallan o se comportan de manera inesperada? ¿Contamos con los controles necesarios para detectarlo antes de que se convierta en un incidente? Y si algo sale mal mañana, ¿podemos demostrar que lo gestionamos de manera responsable?
La arquitectura de gobernanza de IA de cinco capas es la que permite responder a esas preguntas. Enfóquelo así, no como un programa de cumplimiento, sino como la infraestructura operativa que permite a la organización utilizar la IA de forma ambiciosa porque el riesgo se comprende de verdad y se gestiona continuamente. Este enfoque es muy diferente al de un ejercicio de alineación con el NIST.
Si necesita datos para justificar la necesidad de disponibilidad continua ante la dirección, el informe " Sprinto Vendor Category Landscape 2026" ofrece una base sólida. De los 201 proveedores y 16 categorías analizados, una parte significativa obtiene ahora una alta puntuación en dependencia del control en tiempo de ejecución, lo que significa que la exposición no depende únicamente de la postura del proveedor, sino también de cómo se configuran, integran y utilizan internamente las herramientas. El informe concluye que las evaluaciones estáticas son insuficientes en un entorno dependiente del tiempo de ejecución. Este es el argumento a favor de la disponibilidad continua, plasmado en cifras.
Sprinto puede ayudar a poner en marcha una pila de gobernanza de IA siempre activa.
Así es como Sprinto te ayuda en cada nivel:
En la capa de gobernanza de datos , Sprinto ayuda a los equipos a construir bases más sólidas al conectar los controles, verificaciones, políticas y evidencias relacionados con la IA con el sistema de cumplimiento subyacente. Su capa de datos preparada para la IA está diseñada para brindar a las capacidades de IA un contexto coherente en todas las entidades de GRC, de modo que los equipos puedan trabajar con datos de gobernanza estructurados y confiables en lugar de registros dispersos.
En la capa de gobernanza de modelos y proveedores , Sprinto admite la debida diligencia de proveedores basada en IA, el análisis de cuestionarios de seguridad, el mapeo de riesgos a controles y el mapeo de políticas a controles. Esto ayuda a los equipos a evaluar sistemas de IA de terceros, detectar señales de riesgo en la documentación del proveedor y vincular esos hallazgos con los controles y flujos de trabajo de remediación adecuados.
En la capa de integración del sistema , el mapeo de controles a verificaciones de Sprinto vincula las verificaciones del sistema en tiempo real con los controles, lo que ayuda a las organizaciones a pasar de la gobernanza puntual a la monitorización continua del cumplimiento. AI Playground también permite a los equipos crear acciones de IA personalizadas en políticas, riesgos, evidencia, proveedores y otras áreas de GRC sin necesidad de asistencia técnica.
En la capa de control y monitorización , Sprinto AI ayuda a detectar deficiencias con antelación mediante el análisis de brechas de evidencia, evaluaciones de brechas de políticas, información sobre la debida diligencia de proveedores y recomendaciones de control de riesgos. Próximamente, Sprinto planea ampliar estas funcionalidades con agentes proactivos, detección de desviaciones de políticas, identificación de riesgos integral, sugerencias de corrección de monitores y orientación para la corrección de configuraciones externas. Estos elementos de la hoja de ruta están sujetos a cambios, pero apuntan hacia un modelo de gobernanza más autorreparable donde los problemas se detectan y se resuelven antes de que se conviertan en obstáculos para la auditoría.
En la capa de auditoría y evidencia , Sprinto ayuda a los equipos a mantener la gobernanza sólida al convertir la actividad de control en evidencia revisable. El análisis de brechas de evidencia señala la evidencia faltante, obsoleta o irrelevante durante las cargas, mientras que la próxima revisión de evidencia previa a la auditoría y la recopilación de evidencia basada en el navegador buscan que la preparación de la auditoría sea más continua y menos manual.
El resultado es una plataforma de gobernanza de IA que no depende de que alguien recuerde revisar manualmente cada capa.
Lectura adicional: Prepare su programa de gobernanza de IA para el futuro.
Preguntas Frecuentes
Comience con el descubrimiento y la Capa 1. No se puede gobernar lo que no se ha encontrado, ni se puede gobernar un modelo sin gobernar los datos que lo alimentan. Una vez que tenga un inventario y una gobernanza de datos básica, pase a la Capa 4, es decir, la monitorización, antes de perfeccionar las Capas 2 y 3. La razón es que la monitorización le indica cuándo algo falla. Operar sin ella significa que los problemas surgen a través de incidentes en lugar de controles. Las Capas 2, 3 y 5 se pueden construir progresivamente junto con las operaciones en vivo. No espere a tener una pila perfecta antes de la puesta en marcha. Una pila parcial que esté en funcionamiento es más defendible que una pila completa que solo existe en papel.
En la práctica, los cuatro tienen un papel que desempeñar, y ese es precisamente el problema. Cuando la responsabilidad se distribuye sin una función central definida, la gobernanza de la IA queda sin un responsable claro. El departamento de TI adquiere las herramientas, el departamento legal revisa los contratos, el departamento de seguridad evalúa a los proveedores y el departamento de ingeniería implementa las funcionalidades. Nadie considera el riesgo del ciclo de vida completo. La función de gobernanza de la IA necesita un responsable definido que forme parte de GRC o de una función dedicada al riesgo de la IA, y que tenga la autoridad para establecer estándares, exigir pruebas a otras funciones y escalar los problemas cuando los controles no funcionan como deberían. Las demás funciones se convierten en partes interesadas, en lugar de responsables.
No necesita un programa independiente, pero sí extensiones para el que ya tiene. La norma ISO 27001 rige la seguridad de la información, la confidencialidad, la integridad y la disponibilidad de los datos y los sistemas. La gobernanza de la IA añade dimensiones que la ISO 27001 no cubre: comportamiento del modelo, calidad de la salida, desviación, sesgo, explicabilidad y los riesgos específicos de la toma de decisiones autónoma. La norma ISO 42001 está diseñada para complementar la ISO 27001 y extenderla para los sistemas de IA. El Marco de Gestión de Riesgos de IA del NIST está diseñado para integrarse con los programas de gestión de riesgos existentes, en lugar de reemplazarlos. El enfoque práctico consiste en mapear sus controles existentes con las cinco capas, identificar las brechas e incorporar extensiones específicas para IA en su arquitectura de gobernanza actual, en lugar de crear un sistema paralelo.
No existe una respuesta universal, pero sí hay factores desencadenantes claros. La revalidación debe realizarse cuando el modelo se actualiza o se ajusta, cuando los datos con los que opera cambian sustancialmente, cuando el caso de uso se expande más allá de su alcance original, cuando las métricas de rendimiento superan los umbrales definidos o cuando cambia el contexto regulatorio. Para la monitorización, los umbrales y las rutas de escalamiento deben revisarse al menos trimestralmente, no porque la tecnología lo exija, sino porque los entornos operativos cambian y los umbrales de ayer pueden no reflejar la tendencia actual. Para los casos de uso de alto riesgo, la revalidación debe ser más frecuente y estar documentada formalmente. Para los casos de uso de menor riesgo, se puede justificar una cadencia de revisión menos intensiva, siempre que la capa de monitorización esté realmente activa.
Capa 1Inventarios de datos, documentación de linaje, registros de consentimiento y umbrales de calidad de datos definidos y evidenciados.
Capa 2: Tarjetas modelo, evaluaciones de sesgo, líneas base de rendimiento, registros de revalidación y términos del contrato con el proveedor, incluidas las cláusulas de no capacitación.
Capa 3Documentación de la arquitectura del sistema que muestra los componentes de IA, resultados de las pruebas de integración, evidencia de que existen mecanismos de supervisión humana y que han sido probados.
Capa 4Paneles de control de monitorización, definiciones de umbrales, registros de incidentes, registros de escalamiento, propietarios designados con obligaciones de respuesta definidas.
Capa 5Documentación con control de versiones que refleje el estado actual de cada sistema, evidencia de que los controles funcionaron de forma continua, no solo durante un período de auditoría, y un registro claro de cómo se resolvieron los problemas identificados.
El fallo más común reside en la documentación que describe el sistema en el momento de su lanzamiento, en lugar de cómo funciona actualmente. Los auditores son cada vez más conscientes de esta deficiencia y solicitarán historiales de versiones y evidencia reciente, no solo políticas.
Sí. La arquitectura de cinco capas se aplica independientemente de si se desarrolla o se adquiere una solución. Al utilizar una herramienta de IA de terceros, se hereda el riesgo de gobernanza de dicha herramienta; no se transfiere al proveedor. Aun así, es necesario saber qué datos se envían al modelo, si se utilizan para el entrenamiento, cómo se revisan los resultados antes de que influyan en las decisiones y si se puede demostrar todo lo anterior ante un auditor o regulador. En cierto modo, la IA adquirida es más difícil de gobernar que la IA desarrollada internamente, ya que se tiene menos visibilidad del modelo subyacente, menos control sobre las actualizaciones y menos capacidad para realizar la validación propia. Las secciones de riesgo del proveedor de las capas 2 y 3 existen precisamente debido a esta dinámica.
Autor
Raynah
Raynah es estratega de contenido en Sprinto, donde crea historias que simplifican el cumplimiento normativo para las empresas modernas. En los últimos dos años, ha trabajado en diversos formatos y funciones para que la seguridad y el cumplimiento resulten menos complicados y estén más alineados con las necesidades del negocio.Vaya más allá de la superficie y descubra los aspectos clave sobre gobernanza, riesgo y cumplimiento que realmente importan.
Gana premios digitales por tu éxito en la sala de juntas.
Explora más
Investigaciones y análisis seleccionados para ayudarte a ganarte un lugar en la mesa.
