Cómo hacer visible la IA en la sombra sin frenar el trabajo útil

Una política que dice «use solo IA aprobada» no indica a un equipo de seguridad qué está ocurriendo en realidad. Alguien puede pegar notas de una reunión en un chatbot personal, conectar un asistente al calendario de trabajo o instalar una extensión de IA en el navegador mucho antes de que empiece una revisión formal. La primera pregunta no es si todo uso no autorizado debe llamarse incidente. Es si la organización puede ver los datos, identidades y acciones implicados lo bastante bien para tomar una decisión proporcional.

El National Cyber Security Centre del Reino Unido describe la IA en la sombra como IA que opera fuera de sistemas y procesos aprobados. La implicación práctica es tratar la IA no gestionada como un flujo de trabajo que necesita descubrimiento y alternativas más seguras, no solo como una infracción de los empleados. Una prohibición general puede reducir el uso visible y dejar intacta la necesidad que lo produjo.

Empiece por la exposición, no por una lista de proveedores

Una lista de logotipos aprobados es demasiado burda para el uso moderno de IA. El mismo proveedor puede tener bajo riesgo en un entorno gestionado, con registros de auditoría y datos limitados, y alto riesgo en una cuenta personal con un conector no revisado. La unidad de revisión es la implementación: tipo de cuenta, información introducida, configuración de retención, integraciones, permisos de herramientas y responsable.

Cree tres carriles prácticos. En el primero, la experimentación usa material público o sintético y no se conecta a servicios internos; debería ser fácil de declarar y trasladar a una zona de pruebas aprobada. En el segundo, una herramienta maneja información empresarial, material de clientes, código fuente o datos regulados. Necesita una revisión del flujo de datos antes de convertirse en rutina. En el tercero, un agente puede recuperar archivos, llamar API o cambiar otro sistema. Es software privilegiado, no solo un asistente de escritura, y necesita propietario nombrado, credenciales limitadas, registro y una forma de desactivarlo.

Este enfoque evita dos errores costosos. Tratar cada prueba ocasional como un incidente grave satura la revisión y enseña a ocultar el trabajo. Tratar toda herramienta de IA como inofensiva porque produce texto ignora el acceso que los asistentes conectados pueden acumular. La guía del NCSC sobre IA agéntica recuerda que las salvaguardas y la supervisión deben seguir las acciones que un agente puede realizar.

Haga que informar sea más seguro que ocultar

Gran parte del uso en la sombra indica que una tarea no tiene una vía compatible y aceptable. El personal puede necesitar resumir un documento largo, preparar correspondencia para clientes, traducir material o encontrar información en un archivo desordenado. Si la única respuesta oficial es una cola lenta de tickets, suele ganar el producto de consumo que ya conocen.

Ofrezca una vía breve y no punitiva para informar: qué herramienta se usó, qué tipo de cuenta, qué clase de datos intervino, si estaba conectada a otros servicios y qué tarea facilitó. No exija reconstruir cada prompt antes de decidir si existe un problema. Primero preserve la evidencia relevante sobre cuenta, permisos e integraciones; después determine si hay que rotar credenciales, avisar a propietarios de datos o migrar el flujo.

Un buen proceso de entrada también genera un inventario mejor. Combine informes voluntarios con señales de propósito operativo legítimo, como registros de identidad, inventarios de software autorizado, compras y alertas de pérdida de datos. Cada fuente es incompleta. Juntas muestran dónde se cruzan demanda, exposición y soluciones alternativas sin soporte. La guía del NCSC sobre shadow IT plantea lo mismo: los servicios no oficiales suelen surgir porque la gente intenta terminar su trabajo, no porque quiera derrotar a la seguridad.

Diseñe una aprobación que la gente pueda usar

La meta no es un inventario perfecto, sino una ruta rápida desde un flujo desconocido a otro más seguro. Publique qué se puede usar de inmediato, qué requiere una revisión ligera y qué está prohibido porque expondría datos muy sensibles o daría a un agente autoridad excesiva. Explique el motivo en el lenguaje de la tarea. «Use el espacio de trabajo gestionado para documentos de clientes» es más útil que una página de nombres de proveedores.

Mida el tiempo de espera para un modelo, conector o zona de pruebas solicitados. Si un equipo espera semanas por una capacidad que un sitio público ofrece en minutos, las restricciones por sí solas no cerrarán la brecha. Un plazo corto de aprobación, plantillas de evaluación reutilizables y un entorno de experimentación gestionado son controles de seguridad porque reducen el incentivo para eludirlos.

La evidencia de adopción exige cautela. La encuesta británica encargada por Microsoft y citada por el NCSC informa uso autodeclarado de IA de consumo no aprobada entre sus participantes. No prueba que la misma proporción expusiera datos sensibles, causara incidentes ni represente a todos los países o sectores. Aun así advierte que aceptar una política no mide el trabajo real.

Ponga límites firmes a los agentes

Un agente de IA cambia el modelo de riesgo cuando puede actuar. Un fallo de inyección de prompts, un conector demasiado amplio o una cuenta comprometida pueden heredar todo lo que el agente puede leer o modificar. Revise cada integración por separado: qué identidad usa, a qué datos accede, qué operaciones puede realizar y cómo puede interrumpirla una persona.

Prefiera credenciales de corta duración, cuentas de servicio de alcance reducido, datos de prueba segmentados, confirmación por acción para cambios importantes y registros que vinculen usuario, agente, llamada de herramienta y resultado. Pruebe la ruta de desactivación antes de necesitarla. Un interruptor de emergencia que depende de localizar al desarrollador original o una cuenta personal olvidada no es un control significativo.

Mantenga esta revisión separada de la evaluación del modelo. Un modelo capaz sin acceso interno puede ser apropiado para una tarea de bajo riesgo; un modelo más modesto con amplia autoridad puede crear un problema operativo mucho mayor. Los permisos y rutas de datos merecen la misma atención que la calidad de la respuesta.

Siga resultados que cambian el comportamiento

Cuente más que dominios bloqueados. Siga cuántos flujos declarados se trasladaron a herramientas gestionadas, cuánto tardaron las aprobaciones, cuántos agentes tienen propietario y permisos revisados y si el personal puede explicar la ruta aprobada para tareas comunes. Un aumento inicial de informes sobre IA en la sombra puede indicar que informar se ha vuelto más seguro, no que la situación haya empeorado de repente.

La IA en la sombra no puede gobernarse con un documento de política solamente. Se vuelve manejable cuando las personas pueden sacar a la luz el trabajo útil pronto, los revisores distinguen experimentos de bajo riesgo de implementaciones con datos o agentes y la vía respaldada es lo bastante práctica para competir con la no oficial. La visibilidad es el inicio del control, no una razón para detener el trabajo útil.