La advertencia sobre la IA turbia de Bonfy expone el próximo problema de gobernanza de la seguridad

El CEO de Bonfy, Gidi Cohen, ha identificado una preocupante brecha de gobernanza dentro de los sistemas de IA empresariales aprobados. El acceso legítimo ya no garantiza un resultado adecuado.

Cohen denomina al problema «IA turbia». El término describe el uso por parte de una IA aprobada de datos autorizados de formas que vulneran la intención empresarial, las políticas o las expectativas de los clientes. A diferencia de la IA en la sombra, el propio sistema no está oculto para los equipos de seguridad.

La advertencia llegó a una audiencia más amplia a través de la cobertura de seguridad y Google News. Sin embargo, la historia importante no es otra etiqueta llamativa de ciberseguridad. Es el derrumbe de una suposición conocida: que una tecnología aprobada que opera con permisos válidos es una tecnología gobernada.

Esa suposición funcionaba mejor cuando el software seguía instrucciones predecibles. Un empleado abría un registro, modificaba un campo o exportaba un documento. Los equipos de seguridad podían vincular la acción con una persona, un permiso, una aplicación y una marca de tiempo.

La IA cambia esa relación. Un sistema puede recuperar miles de registros autorizados, inferir conexiones entre ellos y generar un resultado que nadie solicitó directamente. Cada acceso individual puede estar permitido, mientras que el resultado combinado cruza un límite.

Este conflicto sitúa a los equipos de seguridad empresarial entre dos opciones insatisfactorias. Pueden ralentizar la adopción de IA con controles estrictos, o permitir un despliegue rápido sin comprender cada uso posterior de los datos de la empresa.

Ninguna de las dos opciones resuelve el problema central. Las organizaciones necesitan controles que evalúen por qué se usan los datos, no solo si una aplicación puede acceder a ellos.

La IA turbia desplaza el riesgo al interior de los sistemas aprobados

La IA turbia convierte un flujo de trabajo aprobado en un problema de gobernanza sin requerir un empleado malicioso, una aplicación desconocida ni credenciales robadas.

Cohen introdujo el término al hablar de cómo la IA distingue la relevancia de la adecuación. Su argumento se centra en sistemas que operan dentro de plataformas aprobadas y flujos de trabajo intencionales.

El usuario puede tener el rol correcto. La aplicación puede haber superado una revisión de seguridad. Todos los registros subyacentes pueden estar disponibles mediante permisos legítimos.

Aun así, la acción resultante puede entrar en conflicto con la política. Un asistente de IA podría combinar comunicaciones de clientes, detalles contractuales e historial de soporte para generar un perfil de riesgo no autorizado. Cada fuente parece relevante, pero su uso combinado cambia la finalidad de los datos.

La distinción de Cohen importa porque los programas de seguridad suelen tratar la aprobación como un límite de control importante. Una vez que un proveedor, una aplicación, una integración y una identidad superan la revisión, la supervisión suele concentrarse en el acceso no autorizado o el comportamiento sospechoso.

La explicación de Bonfy sobre el concepto afirma que un sistema de IA puede recuperar información permitida y aun así producir un resultado que entra en conflicto con las expectativas del cliente. La empresa lo describe como una IA aprobada que va más allá de los límites previstos en su resumen del concepto de IA turbia.

Esto sigue siendo un enfoque respaldado por un proveedor, no una categoría regulatoria reconocida. Ningún organismo independiente ha establecido «IA turbia» como un término estándar o una clase medible de incidentes.

Aun así, el comportamiento subyacente es suficientemente real como para examinarlo. Los sistemas generativos pueden sintetizar datos entre repositorios, inferir atributos sensibles e iniciar acciones mediante herramientas conectadas. Estas capacidades amplían el significado del acceso autorizado.

Pensemos en un asistente laboral conectado al correo electrónico, documentos, calendarios y registros de clientes. Un gerente le pide que identifique las cuentas con mayor probabilidad de cancelar durante el trimestre.

El asistente podría inferir tensión financiera a partir de disputas de facturación. Podría extraer insatisfacción de conversaciones privadas con soporte. También podría conectar esos hallazgos con fechas de renovación contractual y comentarios de empleados.

Cada fuente podría estar dentro de los permisos técnicos del gerente. Sin embargo, es posible que la organización nunca haya aprobado esa finalidad combinada de elaboración de perfiles. También podría carecer de un registro de los factores que dieron forma a la recomendación.

Esto es distinto de la IA en la sombra convencional. La IA en la sombra generalmente se refiere a empleados que usan modelos no aprobados, cuentas personales de chatbots, extensiones de navegador o agentes no autorizados.

En esos casos, el problema de seguridad comienza con la visibilidad. Los equipos deben descubrir qué herramientas están activas, determinar qué datos se introdujeron en ellas y decidir si bloquear o gobernar su uso.

The Hacker News ha descrito otra versión de ese riesgo dentro del software aprobado. Las funciones de IA pueden aparecer en mesas de ayuda, sistemas documentales y plataformas de clientes existentes después de la revisión original del proveedor.

Su análisis de los riesgos de la IA en la sombra sostiene que evaluar previamente un software no gobierna todas las funciones de IA habilitadas posteriormente. Esa observación reduce la distancia entre la IA en la sombra y el enfoque más reciente de Cohen.

Los dos conceptos siguen describiendo fallos de control diferentes.

La IA en la sombra pregunta si la organización sabe que existe una herramienta o función. La IA turbia pregunta si el comportamiento de un sistema aprobado sigue siendo adecuado para un usuario, una finalidad y una relación específicos.

Google News puede situar ambas historias bajo el mismo tema amplio de seguridad de la IA. Los defensores empresariales no pueden permitirse tratarlas como el mismo problema operativo.

Las herramientas de descubrimiento pueden revelar un chatbot desconocido. No pueden decidir automáticamente si un asistente aprobado debería utilizar una conversación sensible con un cliente para influir en una decisión de ventas.

Esa decisión requiere contexto. También requiere una política que el software pueda evaluar antes de la recuperación, generación o acción.

Por qué los controles de identidad y acceso ya no son suficientes

Los controles de identidad responden quién puede acceder a los datos, pero la IA turbia obliga a las organizaciones a decidir qué relaciones y finalidades hacen apropiado ese acceso.

El control de acceso tradicional concede permisos mediante roles, grupos, propiedad de recursos y reglas de política. Un gerente de soporte al cliente podría leer todos los casos asignados a una región. Un analista financiero podría revisar cada factura de una unidad de negocio.

Estos controles siguen siendo esenciales. Impiden que muchos usuarios y aplicaciones no autorizados accedan a sistemas sensibles. También crean registros que los investigadores pueden examinar después de un incidente.

Sin embargo, los permisos amplios suelen existir porque las personas necesitan flexibilidad. Un empleado sénior puede acceder a miles de documentos y utilizar solo un pequeño subconjunto para cada tarea.

El juicio humano proporciona una segunda capa informal. Los empleados normalmente entienden que el acceso a un registro de cliente no autoriza todos los usos posibles de su contenido.

No se puede asumir que la IA comparta esa comprensión. Un modelo optimiza su respuesta utilizando el contexto disponible, las instrucciones y los patrones aprendidos. No conoce de forma inherente los límites no escritos de una organización.

Esto crea un problema de finalidad. Los datos recopilados para atención al cliente pueden estar técnicamente disponibles para un asistente de ventas. Esa disponibilidad no autoriza necesariamente el uso de lenguaje emocional de llamadas de soporte para ajustar el trato comercial.

También crea un problema de relación. Un médico, abogado, gerente de recursos humanos y administrador de sistemas pueden acceder al mismo registro bajo diferentes deberes profesionales.

Un permiso convencional puede representar el recurso y el usuario. Rara vez captura la relación completa que rodea cada inferencia que una IA podría realizar.

Los agentes elevan aún más el riesgo. Un agente de IA es un software que selecciona y realiza acciones mediante herramientas conectadas, en lugar de limitarse a producir texto.

Un agente aprobado podría leer correo electrónico, consultar una base de datos, actualizar un registro de cliente y enviar un mensaje. Sus permisos pueden ser válidos en cada paso.

La secuencia combinada aún puede ser insegura. Una instrucción no confiable oculta dentro de un correo electrónico podría redirigir el comportamiento del agente. Un objetivo amplio también podría fomentar una recuperación excesiva o una acción innecesaria.

OWASP describe la inyección de prompts como instrucciones que manipulan un modelo mediante una entrada directa o contenido que el modelo procesa posteriormente. El impacto depende en gran medida de las herramientas y la autoridad disponibles para el sistema, según su guía sobre inyección de prompts.

Esta amenaza conecta los exploits de seguridad con los fallos de gobernanza. Una instrucción maliciosa puede provocar una acción inapropiada, pero una política poco clara puede producir un resultado similar sin que haya un atacante.

OWASP advierte por separado sobre la agencia excesiva, cuando un sistema de IA tiene más funcionalidades, permisos o autonomía de los que necesita. Su ejemplo incluye un correo electrónico malicioso que ordena a un agente buscar en una bandeja de entrada y reenviar información sensible.

El principio de mínimo privilegio sigue siendo parte de la respuesta. Un asistente no puede hacer un uso indebido de datos o funciones a los que no puede acceder.

Sin embargo, reducir únicamente los permisos tiene límites. Las organizaciones suelen desplegar IA precisamente porque puede conectar información entre sistemas. Eliminar toda capacidad entre sistemas puede acabar con el valor empresarial que justificó el despliegue.

La tarea más difícil consiste en hacer que la autorización sea más específica. Una decisión debe considerar la identidad solicitante, la finalidad empresarial, la relación con los datos, la acción, el destino y el contexto actual.

Por ejemplo, un asistente de atención al cliente podría resumir una queja para el caso asignado. Ese mismo asistente no debería añadir información de salud extraída de esa queja a un perfil de marketing.

Ambas acciones involucran la misma identidad y los datos subyacentes. La diferencia reside en la finalidad, la audiencia y el uso esperado.

Por eso la IA turbia es fundamentalmente un desafío de gobernanza. Los equipos de seguridad pueden definir límites técnicos, pero los responsables legales, de privacidad, cumplimiento, producto y negocio deben definir el comportamiento adecuado.

Esa propiedad compartida resulta incómoda. Las organizaciones de seguridad prefieren reglas aplicables, mientras que los equipos de políticas suelen redactar principios que dependen de la interpretación humana.

Los sistemas de IA exponen la brecha entre esos enfoques. Una política que dice que los datos de clientes deben utilizarse «adecuadamente» ofrece poca protección a menos que la organización convierta esa palabra en controles verificables.

Google News pone de relieve un cambio del acceso a la intención

El debate más amplio sobre seguridad está pasando de descubrir herramientas de IA a gobernar qué hacen los modelos y agentes aprobados con accesos legítimos.

La aparición de la IA turbia en Google News refleja un cambio más amplio en la cobertura de seguridad empresarial. La primera ola de preocupación se centró en empleados que pegaban datos sensibles en chatbots públicos.

Ese riesgo no ha desaparecido. Las cuentas personales, las aplicaciones no aprobadas y las funciones de IA integradas siguen creando problemas de visibilidad y pérdida de datos.

Sin embargo, los despliegues empresariales aprobados presentan ahora una pregunta más compleja. Las organizaciones están conectando asistentes y agentes a sistemas valiosos porque las interfaces de chat aisladas ofrecen un valor operativo limitado.

Las conexiones crean contexto. También crean autoridad.

Un modelo conectado a una base de conocimiento corporativa puede localizar información interna. Un agente conectado a software operativo puede actuar sobre esa información. Por lo tanto, la gobernanza debe abarcar tanto la interpretación como la ejecución.

La investigación de IBM sobre brechas de 2025 detectó una importante brecha de supervisión en torno a la IA empresarial. Su comunicado oficial indicó que el 13 por ciento de las organizaciones estudiadas reportaron brechas que involucraban modelos o aplicaciones de IA.

Entre esas organizaciones, el 97 por ciento carecía de controles adecuados de acceso a la IA. IBM también señaló que el 63 por ciento de las organizaciones encuestadas no tenía políticas de gobernanza de IA o todavía las estaba desarrollando.

Estas cifras proceden de una investigación patrocinada por un proveedor y no deberían definir el riesgo de todas las organizaciones. Aun así, muestran por qué la seguridad de la IA ha ido más allá de los ataques hipotéticos contra modelos.

Los hallazgos de IBM sobre brechas describen una adopción que avanza más rápido que la gobernanza. Shady AI identifica una posible consecuencia de ese desequilibrio dentro de sistemas autorizados.

Los marcos existentes proporcionan bases útiles. El marco de IA de NIST organiza la gestión del riesgo de IA en torno a gobernar, mapear, medir y gestionar el riesgo.

NIST también publicó un perfil para IA generativa que adapta el marco a riesgos específicos de los modelos. Hace hincapié en responsabilidades documentadas, pruebas, procesos de incidentes y medición continua.

Estas prácticas ayudan a las organizaciones a superar la aprobación puntual. Animan a los equipos a tratar la IA desplegada como un sistema cambiante que requiere supervisión continua.

Aun así, un marco no puede proporcionar las reglas de negocio de cada empresa. Un banco, un hospital, un proveedor de software y una universidad definirán de forma distinta el uso adecuado de los datos.

La regulación añade otra capa. Las normas de la Unión Europea imponen obligaciones a proveedores y responsables del despliegue según el papel y la clasificación de riesgo de un sistema de IA.

La Comisión Europea afirma que las obligaciones para los modelos de propósito general comenzaron a aplicarse el 2 de agosto de 2025. Incluyen requisitos de documentación y transparencia, junto con obligaciones adicionales para los modelos clasificados como de riesgo sistémico.

Estas normas se centran en gran medida en los proveedores y los casos de uso designados. No resuelven automáticamente todas las decisiones contextuales que toma un asistente empresarial que utiliza datos internos autorizados.

Una organización podría cumplir los requisitos de documentación del proveedor y, aun así, desplegar un asistente con fines internos mal definidos. El cumplimiento legal y la idoneidad operativa se solapan, pero no son lo mismo.

La misma distinción aparece en la legislación sobre privacidad. El consentimiento u otra base jurídica puede autorizar el tratamiento de datos a alto nivel. Una nueva inferencia o un conjunto de datos combinado todavía puede generar consecuencias inesperadas.

Aquí resulta útil la frase «la relevancia no es permiso». Una información puede mejorar la respuesta de un modelo sin ser adecuada para esa decisión.

Los motores de búsqueda y Google News suelen favorecer categorías simples, como shadow AI, agentes de IA y filtración de datos. Shady AI no encaja limpiamente en ninguna de ellas.

Se sitúa entre la gestión de accesos, la privacidad, el comportamiento de los modelos, la gobernanza de datos y el diseño de procesos de negocio. Esa superposición dificulta asignar responsabilidades y facilita que se pase por alto.

Por tanto, la organización bajo presión no es solo el centro de operaciones de seguridad. Los responsables de seguridad de la información, líderes de privacidad, equipos legales, propietarios de datos y gestores de aplicaciones heredan todos una parte del problema.

Necesitan una visión única y exigible del comportamiento permitido. Sin ella, cada equipo puede creer que otro grupo es dueño del riesgo.

La Parte Difícil Es Convertir la Política en Decisiones en Tiempo de Ejecución

Una respuesta creíble debe aplicar el contexto durante la recuperación y la acción, no limitarse a publicar otra política de uso aceptable.

Muchas organizaciones comenzaron la gobernanza de IA con listas. Una enumera las herramientas aprobadas. Otra identifica los datos prohibidos. Una tercera asigna propietarios de aplicaciones y fechas de revisión.

Esos inventarios son necesarios, especialmente para descubrir shadow AI. No abordan por completo un sistema aprobado que produce un resultado inapropiado a partir de recursos permitidos.

Shady AI exige controles más próximos al tiempo de ejecución. El tiempo de ejecución es el momento en que una IA recibe una solicitud, recupera información, genera una salida o invoca una herramienta conectada.

En ese momento, el sistema dispone de más contexto que un proceso de aprobación estático. Conoce al usuario, la solicitud, los datos seleccionados, el destino previsto y la acción propuesta.

Una capa de gobernanza puede evaluar esos factores antes de permitir que el flujo de trabajo continúe. Puede denegar el acceso, eliminar contexto sensible, exigir aprobación o limitar la acción disponible.

La política debe ser lo bastante específica para poder aplicarse. «Proteger la confianza del cliente» es un principio importante, pero el software necesita una regla más precisa.

Una regla podría prohibir que un asistente use conversaciones de soporte para determinar descuentos. Otra podría restringir la información médica de empleados para que no se resuma fuera de un flujo autorizado de prestaciones.

Las organizaciones también necesitan procedencia, que registra de dónde obtuvo una respuesta de IA su información. La procedencia ayuda a los revisores a entender qué fuentes influyeron en una respuesta o acción.

Registrar únicamente el prompt final y la respuesta es insuficiente para muchos flujos de trabajo agénticos. Los investigadores pueden necesitar los documentos recuperados, las llamadas a herramientas, las evaluaciones de políticas, la versión del modelo y el historial de aprobaciones.

Ese registro respalda las auditorías y la respuesta a incidentes. También puede revelar reglas de política que bloquean trabajo inocuo o permiten combinaciones arriesgadas.

Las pruebas deben reflejar relaciones comerciales reales. Los benchmarks genéricos de modelos no pueden determinar si un mensaje concreto de un cliente debe formar parte de una recomendación de renovación.

Los equipos deberían crear escenarios basados en sus propios datos, roles, flujos de trabajo y resultados prohibidos. Las pruebas deberían incluir tanto prompts maliciosos como solicitudes habituales con fines ambiguos.

La aprobación humana puede reducir el riesgo de acciones de alto impacto. Resulta más útil cuando el revisor recibe el contexto pertinente y un motivo comprensible para la alerta.

Un botón con la etiqueta «aprobar» sirve de poco si el revisor no puede ver qué fuentes sensibles dieron forma a la acción. La fatiga de aprobación también puede convertir un control formal en un clic automático.

Por ello, las organizaciones deberían reservar la revisión humana para límites significativos. Los flujos de menor riesgo pueden usar restricciones automatizadas, muestreo y supervisión retrospectiva.

La minimización de datos es otro control práctico. Un asistente debería recibir únicamente la información necesaria para su tarea actual, incluso cuando su cuenta de servicio pueda acceder a más.

Los sistemas de recuperación pueden aplicar esa restricción antes de que el contenido entre en el contexto del modelo. Las puertas de enlace de herramientas pueden limitar de forma similar qué operaciones puede realizar un agente.

Para los trabajadores del conocimiento, el contexto local puede reducir transferencias innecesarias a servicios externos amplios. Una base de conocimiento personal bien diseñada puede preservar límites más claros entre la información personal y la información organizativa compartida.

Sin embargo, la arquitectura por sí sola no garantiza un uso adecuado. El procesamiento local puede reducir la exposición y, aun así, producir una inferencia injusta, intrusiva o no autorizada.

Este es un punto escéptico importante. Los proveedores de seguridad pueden describir la aplicación contextual como una respuesta completa, pero la interpretación de políticas sigue siendo difícil.

El lenguaje natural es ambiguo. Las relaciones comerciales cambian. Una regla que funciona para un departamento puede obstaculizar a otro equipo o pasar por alto un uso indebido sutil.

Los falsos positivos pueden llevar a los empleados a buscar soluciones alternativas. Los falsos negativos pueden generar una confianza injustificada en una capa automatizada de gobernanza.

El comportamiento del modelo también cambia tras las actualizaciones. Un prompt, una estrategia de recuperación o una prueba de política que funcionaba con una versión puede comportarse de manera diferente con otra.

Las organizaciones deberían tratar los controles contextuales como parte de un programa por capas. La identidad, el privilegio mínimo, la clasificación de datos, el filtrado de recuperación, las restricciones de herramientas, la evaluación y la supervisión humana siguen siendo necesarios.

Ningún control único demuestra que todos los resultados sean adecuados. El objetivo es hacer que las infracciones de política sean visibles, comprobables y más difíciles de ejecutar a velocidad de máquina.

Tres Señales Mostrarán Si Shady AI Se Convierte en una Categoría Real de Seguridad

Shady AI solo importará si las organizaciones pueden medirlo, aplicar controles significativos y vincular los fallos con responsables identificables.

La primera señal es si los principales marcos de seguridad distinguen el uso autorizado inapropiado de la IA no autorizada convencional. NIST, OWASP y grupos del sector ya abordan aspectos relacionados.

La inyección de prompts abarca el comportamiento manipulado de los modelos. La agencia excesiva abarca una autonomía peligrosa. Shadow AI abarca sistemas desconocidos o no autorizados.

Ninguna de esas etiquetas describe a la perfección un sistema aprobado que toma una decisión contextualmente inaceptable sin que exista un atacante. Una taxonomía más clara ayudaría a los equipos a informar incidentes de manera coherente.

Esté atento a nueva orientación de marcos que aborde el propósito, la relación y la inferencia. Esa orientación reforzaría el argumento de Cohen de que los controles de acceso convencionales dejan una brecha material.

Ese juicio se debilitaría si las categorías existentes ya capturan estos incidentes sin confusión operativa. La nueva terminología aporta poco valor cuando solo renombra fallos establecidos.

La segunda señal es la llegada de controles medibles en tiempo de ejecución. Los proveedores prometerán gobernanza contextual, pero los compradores deberían buscar evidencia más allá de los paneles de políticas.

La evidencia útil incluye restricciones de finalidad exigibles, registros de decisiones, controles a nivel de recuperación, aprobaciones de llamadas a herramientas y pruebas repetibles. Los productos también deberían explicar por qué una política permitió o denegó una acción.

Las evaluaciones independientes serían especialmente valiosas. Un proveedor no debería ser la única parte que define el riesgo, mide su producto y declara que el control ha tenido éxito.

Los compradores deberían probar escenarios realistas antes de un despliegue amplio. Deberían preguntar si el sistema detiene combinaciones de datos inapropiadas, no solo prompts maliciosos conocidos.

También deberían examinar los modos de fallo. Un control que bloquea flujos de trabajo legítimos con demasiada frecuencia perderá respaldo, aunque su lógica de seguridad parezca sólida.

La tercera señal es la responsabilidad organizativa. Shady AI cruza las responsabilidades de seguridad, privacidad, legal, datos y producto.

Un comité de gobernanza puede coordinar esos equipos, pero los comités suelen producir orientación sin propiedad operativa. Cada sistema desplegado sigue necesitando una persona responsable de las decisiones.

Ese responsable debería aprobar los fines previstos, las relaciones de datos aceptables, los resultados prohibidos y las reglas de escalamiento. Los equipos de seguridad pueden traducir entonces esas decisiones en controles técnicos y pruebas.

La notificación de incidentes revelará si ese modelo funciona. Las organizaciones deberían poder distinguir entre una herramienta desconocida, un agente comprometido, un fallo de permisos y una acción autorizada inapropiada.

Estas categorías conducen a soluciones diferentes. Bloquear un dominio puede abordar un chatbot no autorizado, pero no puede gobernar un modelo aprobado ya integrado en una aplicación empresarial.

La exposición en Google News atraerá más atención hacia Shady AI, pero la atención por sí sola no consolidará el término. La evidencia procedente de sistemas desplegados debe mostrar un fallo recurrente que los controles existentes pasan por alto de forma sistemática.

Los líderes de seguridad deberían comenzar con un inventario limitado de flujos de trabajo de IA aprobados que afecten datos sensibles o decisiones relevantes. Para cada flujo, deberían formular cuatro preguntas.

¿Qué información puede recuperar el sistema? ¿Qué finalidades justifican esa recuperación? ¿Qué acciones puede realizar? ¿Quién puede explicar y detener un resultado inapropiado?

Si esas preguntas producen respuestas vagas, la brecha de gobernanza ya existe. Los equipos no necesitan esperar a una brecha, una regulación o una nueva categoría de producto para examinarla.

El siguiente paso práctico es seleccionar un flujo de trabajo de alto impacto y rastrearlo desde la solicitud hasta el resultado. Registre identidades, datos recuperados, políticas, decisiones del modelo, llamadas a herramientas y aprobaciones humanas.

Después, pruebe solicitudes que estén técnicamente permitidas pero sean contextualmente incorrectas. Ese ejercicio mostrará si «aprobado» realmente significa gobernado, o simplemente conectado y de confianza.