5 estrategias de gobernanza de IA que no obstaculizan a los equipos: la guía práctica para profesionales.

Imagina que los datos salen del entorno a través de herramientas no verificadas porque nadie le avisó al equipo de ventas que su herramienta de toma de notas con IA no estaba en la lista de aprobadas. O que el código generado por IA llega a producción sin revisión porque el equipo de ingeniería asumió que el modelo ya lo había comprobado. Apostamos a que estas son pesadillas que no querrías ver hechas realidad. 

El problema radica en que la mayoría de las respuestas de gobernanza de la IA generan un tipo de daño diferente: equipos ralentizados, experimentos cancelados antes de comenzar, ganancias de productividad que se transfieren a la competencia mientras su organización lleva a cabo un ciclo de aprobación de 8 semanas para un experimento de dos horas. 

Nuestro informe "Estado de la IA en Riesgo 2026" reveló que dos de cada tres organizaciones tardan entre una semana y seis meses en implementar controles o cambios en las políticas en respuesta a los riesgos relacionados con la IA. Sin embargo, cuando la implementación de controles o actualizaciones de políticas para riesgos relacionados con la IA se demora demasiado, los equipos de GRC terminan estancando herramientas prometedoras o viendo cómo los empleados las utilizan sin autorización. Y ambos resultados aumentan el riesgo.

La pregunta que los profesionales se plantean actualmente es: ¿cómo controlar el riesgo real sin convertirse en un obstáculo para el negocio? Esta pregunta está presente en todas partes; basta con ver estos hilos de Reddit, por ejemplo:

En este blog, hemos recopilado las mejores recomendaciones de usuarios de Reddit sobre cómo implementar la gobernanza de la IA para que sirva como facilitadora en lugar de como obstáculo.   

Blog en pocas palabras

1. Reemplazar el binario de permitir/bloquear con un modelo de tres carriles (verde/amarillo/rojo).

Una buena idea para un marco de trabajo de fácil implementación provino de un experto en r/devsecops que había experimentado las dificultades iniciales de la seguridad en la nube y reconoció que el mismo patrón se repetía. Su argumento: dejar de tratar la IA como algo categóricamente diferente de otros riesgos de infraestructura y comenzar a clasificar las rutas de riesgo reales.

Una de las respuestas más estructuradas del hilo provino de un comentarista que representaba a un proveedor en el espacio de seguridad de datos de IA, en el hilo de r/devsecops "¿ Cómo manejan las personas la seguridad de datos de IA sin bloquear todos los experimentos internos de IA?" , "Lo que nos funcionó fue un modelo de 3 carriles. Carril verde: datos públicos o de baja sensibilidad, copilotos SaaS aprobados, registro normal. Carril amarillo: datos internos con contratos, límites de retención, sin entrenamiento en las indicaciones, DLP en la entrada y salida, y revisión humana antes del uso en producción. Carril rojo: datos regulados, secretos de clientes, volcados de producción, origen vinculado a flujos de autenticación: solo modelos internos aislados o ninguna IA en absoluto". Desde la perspectiva del proveedor o no, la lógica se mantiene y se corresponde directamente con cómo los equipos de seguridad maduros abordaron el riesgo en la nube hace una década y los requisitos de la Ley de IA de la UE en la actualidad.

Otro usuario, u/Heavy-Foundation6154, comentó en el mismo hilo: «Un chatbot interno cuyos chats no se utilizan como datos de entrenamiento supone un nivel de riesgo diferente al de un agente externo que tiene acceso a bases de datos internas». El destino es tan importante como el tipo de datos.

En conjunto, estos dos comentarios describen un marco que anticipa la respuesta a la decisión, de modo que los empleados no técnicos nunca tengan que tomar una decisión que esté más allá de su comprensión. 

Los carriles son definidos previamente por el equipo de GRC o de seguridad dentro de una matriz de clasificación que asigna los tipos de datos a los destinos de IA aprobados, y se mantienen del mismo modo que se mantiene un inventario de datos. Los equipos acceden a la matriz y actúan en consecuencia.

Por ejemplo: Un equipo de marketing que usa IA para redactar contenido para el blog revisa la matriz, ve que está en verde y elige de la lista de herramientas aprobadas; el contenido se iba a publicar de todos modos. Un equipo de ventas que usa IA para resumir las notas de las llamadas antes de una propuesta revisa la matriz, ve que está en amarillo y sabe que necesita una herramienta con licencia empresarial y un acuerdo de protección de datos (DPA) antes de continuar; los términos del acuerdo y el contexto del cliente no están regulados, pero tampoco son públicos. Un analista de tecnología sanitaria que está considerando procesar los registros de pacientes con algún modelo externo revisa la matriz, ve que está en rojo y sabe que la respuesta es no. 

Este modelo también se adapta a marcos de trabajo ya establecidos sin necesidad de reconstruirlo para cada uno de ellos. 

• Las funciones de Gobernar y Mapear del Marco de Gestión de Riesgos de IA del NIST siguen la misma lógica, es decir, clasifican el caso de uso, asignan el nivel de riesgo y aplican los controles. 
• La Ley de IA de la UE es más específica: su sistema de niveles de riesgo se corresponde casi directamente con los tres carriles, y los casos de uso de IA de alto riesgo, como la calificación crediticia, la contratación, los dispositivos médicos y las infraestructuras críticas, se clasifican en rojo por normativa, no solo por política interna. Para las organizaciones que operan en la UE, el modelo de tres carriles no solo es una cuestión de gobernanza interna, sino también la forma de identificar qué usos generan obligaciones de cumplimiento obligatorias por ley.

2. Aplicar en la capa de datos, no en el perímetro de la red.

Si tu primer instinto al detectar un riesgo en la IA es bloquearla en el cortafuegos, no estás solo, y tienes razón al actuar con cautela. Sin embargo, el cortafuegos no es el lugar adecuado para garantizar la gobernanza de la IA, y aquí te explicamos por qué no funciona.

Como comentó u/Cautious_Map25 en el hilo de r/devsecops " ¿Cómo gestionan las personas la seguridad de los datos de IA sin bloquear todos los experimentos internos de IA?" , "La mayoría de los equipos que lo hacen bien no prohíben la IA, sino que optan por un modelo de habilitación controlada. Se centran en la visibilidad en tiempo real de los datos que se utilizan en las solicitudes y los flujos de trabajo de IA, además de políticas sencillas que guían su uso en lugar de impedirlo".

El hilo también abordó con detalle dónde debe ubicarse realmente ese control. Como lo expresó u/Master_Baby_2700: «Lo que parece funcionar mejor es tratar la IA como cualquier otra capa de acceso a datos: clasificar los datos confidenciales, supervisar a qué pueden acceder las aplicaciones/conectores de IA y establecer límites para los conjuntos de datos de alto riesgo en lugar de bloquearlo todo globalmente». Las cuentas personales, los navegadores móviles y las redes domésticas no se enrutan a través del proxy corporativo. Los controles de la capa de red se diseñaron para un modelo de amenazas diferente.

El riesgo de enviar datos a un modelo alojado internamente es estructuralmente diferente al de enviarlos a un producto gratuito para el consumidor. Tratarlos de la misma manera genera una gobernanza que, por un lado, es demasiado estricta en algunos aspectos y, por otro, demasiado laxa en otros.

3. Cerrar la brecha para la que CASB nunca fue construido  

La brecha en Cloud Access Security Broker fue explicada por u/Effective_Guest_4835, un profesional de la seguridad que publicó en el hilo de r/AskNetsec, " Recomendaciones de herramientas de gobernanza de IA para una empresa tecnológica que no puede bloquear la IA por completo, pero necesita visibilidad y control " . Guest_4835 dirigía la seguridad de una empresa tecnológica de rápido crecimiento y ya había agotado las herramientas estándar. En sus palabras: "El uso de IA basado en navegador en cuentas personales se realiza a través de sesiones HTTPS que la mayoría de los controles integrados no detectan. Esa brecha entre lo que CASB detecta y lo que realmente sucede en una pestaña del navegador es donde reside la mayor parte de la vulnerabilidad".

Tu CASB detecta que alguien visitó claude.ai, pero no encuentra información sobre el contenido que pegaron. ¿Qué pasaría si pegaran un contrato sin ejecutar, un registro de cliente o paciente, un modelo de crédito o código fuente propietario? 

CASB se diseñó para la visibilidad de SaaS, no para lo que ocurre dentro de una sesión de navegador cifrada. Los expertos que respondieron a este hilo recomendaban controles a nivel de navegador que se ubican dentro de la pestaña, para ver qué se escribe, copia y sube antes de que salga. Puede marcar el contenido pegado de información personal identificable (PII), bloquear la subida a una herramienta gratuita o advertir al usuario antes de que envíe el mensaje. El punto de exposición es la solicitud de confirmación, y ahí es donde se ubican estos controles.

4. Asegúrese de que la ruta segura sea realmente más rápida que la solución alternativa.

Este es el principio de diseño que mantiene todo unido, y fue expresado de forma sencilla por u/BasilThis2161 en un hilo titulado " ¿Cómo se gestiona la seguridad de los datos de IA sin bloquear todos los experimentos internos de IA? " . Dice: "Descubrimos que proporcionar a los desarrolladores un entorno 'seguro' específico con un acuerdo empresarial era la única manera de mantener la visibilidad de lo que estaba sucediendo".

La gobernanza es tanto un problema de experiencia como de política. Si usar una herramienta empresarial aprobada es más rápido y sencillo que usar una cuenta personal, la gente la usará y se mantendrá la visibilidad. Si el proceso aprobado requiere la revisión de un comité y una espera de seis semanas para una prueba de dos horas, la gente usará sus teléfonos y no habrá ni cumplimiento ni visibilidad. El mecanismo por el cual la gobernanza funciona a gran escala consiste en convertir la opción segura en la opción fácil. 

Dicho esto, no siempre es posible convertir el camino más seguro en el más rápido.

Es entonces cuando las conversaciones individuales y la empatía cobran importancia. Ofrece tu apoyo, no tus obstáculos. Podrías intentar algo como: «Entiendo por qué esto es útil. Quiero ayudarte a lograrlo. Solo necesito asegurarme de que no estemos exponiendo datos de clientes, otorgando permisos riesgosos o creando algo que no podamos monitorear. Busquemos la ruta más rápida y segura». Ayudar al equipo a comprender los riesgos, las implicaciones y las posibles consecuencias graves suele ser de gran ayuda. 

En ocasiones, una herramienta puede resultar inviable. En esos casos, el objetivo no es rechazar la solicitud, sino comprender qué intentaba hacer el equipo y encontrar una alternativa más segura: un proveedor preaprobado, permisos más restringidos, datos aislados, una clave temporal o un flujo de trabajo diferente.

5. Crea el registro de auditoría antes de que alguien lo solicite.

Muchos equipos de GRC ya cuentan con infraestructura de registro, pipelines SIEM y procesos de auditoría, pero aún están construyendo la capa específica de IA sobre ellos. El problema no radica en que los equipos desconozcan la necesidad de evidencia, ni siquiera en que no se esfuercen por recopilarla. El problema es que, cuando el auditor, el adquirente o el equipo de seguridad del cliente potencial la solicitan, la evidencia se encuentra dispersa en cuatro sistemas y nadie es responsable del registro, porque, como lo expresó u/jcarmona86 en el hilo de r/AI_Governance "¿ Dónde reside realmente la evidencia de aprobación de IA en tu organización? ", " La mayoría de las organizaciones aprobaron las herramientas de IA de forma reactiva, herramienta por herramienta, sin un estándar de evidencia definido. El resultado es un conjunto de artefactos en lugar de un registro gobernado. La bandeja de entrada de alguien contiene el correo electrónico de aprobación original. Una carpeta de SharePoint contiene el cuestionario del proveedor. Una página de Confluence contiene las notas de la reunión. La evaluación de riesgos real es un documento de Google editado por tres personas y del que nadie es responsable. Cada uno cuenta una parte de la historia. Ninguno de ellos constituye el registro " .

El registro de aprobación es solo el punto de partida. Para la IA, esto implica ampliar la información que ya se registra: registrar las entradas y salidas de las solicitudes al SIEM, anonimizar las direcciones de correo electrónico y los ID de cuenta a nivel de token antes de que lleguen a las API externas, y mantener un registro de la versión del modelo que se estaba utilizando en ese momento. Las versiones del modelo son importantes porque la misma solicitud puede generar resultados sustancialmente diferentes entre versiones, y cuando el equipo de seguridad de un cliente potencial o un organismo regulador lo solicita, ese registro es lo que genera confianza.

Dos huecos estos mejores prácticas de gobernanza de la IA Los hilos no se cierran

Todo lo anterior se aplica a la IA, tal como la utilizan actualmente la mayoría de las organizaciones: las personas hacen solicitudes y la IA devuelve respuestas. Sin embargo, dos patrones ya están rompiendo ese modelo, y los profesionales del sector reconocen abiertamente que aún están analizando cómo gestionar estos casos de uso.

1. El código generado por IA llega a producción. 

u/Effective_Guest_4835, publicando en el hilo de r/AskNetsec " Recomendaciones de herramientas de gobernanza de IA para una empresa tecnológica que no puede bloquear la IA por completo pero necesita visibilidad y control" , señaló un escenario cada vez más común: ingenieros que usan IA para escribir herramientas internas que terminan ejecutándose en producción sin pasar por ninguna revisión real: un equipo que avanza rápido, la IA lo hace más rápido, nadie pregunta si el código generado tiene acceso a cosas a las que no debería". La velocidad de generación no es lo mismo que la preparación para la producción. El proceso de revisión de código que se aplica al código escrito por humanos se aplica igualmente aquí, en algunos aspectos, incluso más, porque el volumen es mayor y el desarrollador puede tener visibilidad limitada sobre lo que el modelo realmente produjo.

2. IA agente

Este es el problema más complejo. Como señaló u/Unfair-Plum2516 en el mismo hilo: “Gran parte de la ‘gobernanza’ actual se reduce a la observabilidad a posteriori. La pregunta más difícil es: ¿puede el sistema reconocer comportamientos de riesgo antes de que se ejecute la acción? Porque una vez que los agentes tienen acceso a los sistemas de producción, los registros por sí solos no son suficientes. En ese punto, se necesitan límites de ejecución reales, lógica de aprobación y aplicación de políticas dentro del propio flujo de trabajo”.

Cada marco de trabajo descrito anteriormente fue diseñado para un mundo donde la IA responde a comandos. Los sistemas agentes que ejecutan acciones de forma autónoma, encadenan llamadas a la API, envían comunicaciones y modifican registros requieren una capa diferente: límites de ejecución, lógica de aprobación previa a la acción y aplicación de políticas dentro del flujo de trabajo, en lugar de fuera de él. Las personas que participan en estos hilos están trabajando en ello. Nadie lo ha resuelto por completo todavía.

Estrategias que podrían ayudar: 

• Amplíe su política de revisión de código existente para que cubra explícitamente el código generado por IA. Conviértalo en un requisito definido, no en una suposición.
• Para los sistemas basados ​​en agentes que ya están en uso o en evaluación, asigne cada acción del sistema a un punto de control de aprobación humana antes de que se permita su puesta en producción.
• Trate la IA con agentes como una nueva categoría de riesgo en su registro de riesgos. Documente qué acciones puede realizar cada agente, a qué datos puede acceder y cuál es el procedimiento de reversión.

Cómo Sprinto te ayuda a poner en práctica estas Mejores prácticas de gobernanza de la IA

Convertir todas las acciones concretas mencionadas anteriormente en flujos de trabajo, controles y evidencia lista para auditorías sin tener que construir todo desde cero puede parecer desalentador, pero Sprinto puede ayudar. 

1. Crea tu matriz de clasificación en el registro de riesgos de Sprinto.

Defina sus carriles Verde/Amarillo/Rojo como controles, asígnelos a su Política de Uso Aceptable de IA y utilice acciones de IA personalizadas en AI Playground para crear un flujo de trabajo de admisión sin código. Cuando un equipo envía una solicitud de caso de uso de IA, la acción la clasifica según la sensibilidad de los datos, el destino de la IA, el tipo de proveedor y si se trata de datos regulados, y devuelve una clasificación de carril con los controles necesarios. No se requiere ingeniería.

2. Realice una debida diligencia con los proveedores de IA antes de que los equipos adopten las herramientas.

El flujo de trabajo de diligencia debida con IA para proveedores de Sprinto plantea las preguntas clave: ¿el proveedor recibe capacitación sobre las indicaciones del cliente? ¿Existe un acuerdo de protección de datos (DPA)? ¿Se pueden exportar los registros? ¿Es compatible con el inicio de sesión único (SSO) empresarial? ¿Se permiten los datos regulados? La IA de Sprinto acelera el proceso de revisión al generar conclusiones a partir de los documentos de seguridad del proveedor, para que su equipo no tenga que leer manualmente los informes SOC 2.

3. Vincule su política de IA con los controles y las pruebas.

Convierta su Política de Uso Aceptable de IA en un documento interno en Sprinto, asígnele controles y vincule esos controles con verificaciones. Sprinto AI se encarga de la asignación de políticas a controles, de modo que el trabajo de gobernanza que haya realizado se convierte en evidencia lista para auditoría en lugar de un documento archivado.

4. Cerrar las lagunas de evidencia antes de que se conviertan en hallazgos de auditoría.

El análisis de brechas de evidencia de Sprinto detecta evidencia faltante, obsoleta o irrelevante durante las cargas. En el ámbito de la gobernanza de la IA, esto implica el seguimiento de: la lista de herramientas aprobadas, los acuerdos de protección de datos (DPA) de los proveedores, el registro de casos de uso de IA, las evaluaciones de riesgos, los registros de revisión humana del código generado por IA y las certificaciones para el manejo restringido de datos. Cuando se recibe una revisión de seguridad del cliente o una consulta regulatoria, se accede a un conjunto de evidencia actualizado, en lugar de tener que reconstruirlo.

Lo que aprendiste

La gobernanza de la IA falla de dos maneras: es tan laxa que el riesgo se vuelve invisible, o tan estricta que los equipos la eluden y, de todos modos, el riesgo se vuelve invisible. Las organizaciones que lo hacen bien no eligen entre control y velocidad, sino que construyen una gobernanza que convierte el camino seguro en el camino rápido. Esto implica mapear los datos antes de redactar las políticas, establecer protocolos que respondan a las preguntas antes de que se formulen, aplicar medidas de control en el punto de exposición en lugar de en el borde de la red, y contar con un registro de evidencia sólido cuando alguien externo lo solicita. Ninguna de estas buenas prácticas de gobernanza de la IA requiere empezar de cero. Requiere tomar lo que su programa GRC ya hace bien y extenderlo deliberadamente al ámbito de la IA. 

Por último, pero no por ello menos importante, aquí tienes algunos recursos adicionales que te ayudarán a planificar y perfeccionar la gobernanza de tu IA: 

• Descubre cómo tu A sus pares les está yendo bien con la gobernanza de la IA.
• Obtén un hoja de ruta para la gobernanza de la IA basada en cómo otros CISO y responsables de GRC manejan la gobernanza de la IA
• Evaluar Su nivel de madurez en la gobernanza de la IA  

Preguntas Frecuentes