Gestión del riesgo relacionado con los datos en flujos de trabajo basados en la inteligencia artificial
Un empleado del servicio de atención al cliente introduce una reclamación en un asistente de IA y le pide que redacte una respuesta. La reclamación contiene el nombre del cliente, su número de cuenta y su historial médico. La respuesta se genera en cuestión de segundos, se edita y se envía. No se aprecia ninguna brecha de seguridad de forma inmediata, no se activa ninguna alerta de seguridad y el empleado da la tarea por concluida.
Sin embargo, siguen sin respuesta varias cuestiones importantes. ¿Se permitió que la información saliera del entorno controlado de la empresa? ¿La conservó el proveedor de IA? ¿Podría utilizarse para mejorar el servicio o para entrenar modelos? ¿Qué subcontratistas la procesaron? ¿Podría la empresa recuperar la indicación si el cliente impugnara posteriormente la decisión?
Así es como los flujos de trabajo basados en la inteligencia artificial están transformando el riesgo relacionado con los datos. El peligro ya no se limita al robo de una base de datos o a que un empleado adjunte una hoja de cálculo equivocada. La información confidencial pasa ahora por indicaciones, sistemas de recuperación, interfaces de modelos, complementos, agentes automatizados e infraestructuras de terceros. El flujo de trabajo puede ser más rápido, pero el rastro de los datos es más largo y, a menudo, menos visible.
Por lo tanto, la cuestión fundamental desde el punto de vista de la gestión no es si la IA reduce el error humano, sino si la empresa sigue sabiendo qué información se está procesando, por dónde circula, quién puede acceder a ella y qué acciones automatizadas está autorizada a activar.
La automatización puede reducir los errores y multiplicar sus consecuencias
Los controles de datos tradicionales se diseñaron, en gran medida, pensando en sistemas con entradas y salidas predecibles. Una aplicación de nóminas realiza un cálculo definido. Una base de datos de clientes almacena registros en campos conocidos. Se puede conceder acceso en función del puesto de trabajo, mientras que los cambios significativos pueden registrarse y revisarse.
Un flujo de trabajo basado en IA se comporta de forma diferente. Puede clasificar la información que recibe, resumirla, combinarla con documentos internos, generar una recomendación y transmitir dicha recomendación a otro sistema. Cuando intervienen agentes, el modelo también puede enviar un correo electrónico, actualizar un registro, aprobar una solicitud rutinaria o iniciar otro proceso automatizado.
Esto puede eliminar el trabajo manual repetitivo. La IA puede ayudar a detectar patrones de acceso inusuales, identificar información confidencial, clasificar documentos y señalar transacciones para su revisión. También puede reproducir el mismo error en miles de casos antes de que nadie se dé cuenta.
Un empleado que interprete erróneamente una política puede gestionar incorrectamente varios expedientes. Un flujo de trabajo automatizado que utilice esa misma interpretación errónea puede gestionar incorrectamente todos los expedientes que cumplan los requisitos en el sistema. La ventaja en términos de eficiencia y el riesgo de control se derivan de la misma característica: la escala.
Por lo tanto, las empresas deberían dejar de considerar que la “intervención humana” es una respuesta suficiente. Es poco probable que una persona que aprueba varios cientos de decisiones generadas por la IA en una sola tarde pueda evaluar cada una de ellas de forma significativa. La supervisión humana solo resulta útil cuando el revisor dispone de suficiente información, autoridad y tiempo para intervenir.
La línea de comandos se ha convertido en un nuevo canal de transferencia de datos
Muchas organizaciones han pasado años limitando la forma en que los empleados podían exportar listas de clientes, registros financieros y documentos de carácter comercialmente sensible. La IA generativa ha creado una vía menos obvia: el cuadro de comandos.
Un empleado puede pegar parte de un contrato en un asistente para obtener un resumen, cargar datos de ventas para su análisis o facilitar el correo electrónico de un cliente para que el sistema redacte una respuesta. Esta acción puede parecer más parecida al uso de un motor de búsqueda que a la transferencia de datos a un procesador externo, aunque desde el punto de vista del control interno puede que sea precisamente eso.
Esto cambia el significado práctico de la prevención de la pérdida de datos. Ya no basta con supervisar los archivos adjuntos de los correos electrónicos, los dispositivos USB y las plataformas para compartir archivos. Las empresas deben saber a qué interfaces de IA pueden acceder los empleados, qué categorías de información pueden introducirse y qué controles técnicos impiden que el material restringido salga de los entornos autorizados.
Una prohibición general rara vez es una solución eficaz a largo plazo. Los empleados pueden recurrir a cuentas personales o herramientas no autorizadas cuando consideren que la IA mejora de forma significativa su trabajo. Un enfoque más sólido consiste en proporcionar un entorno empresarial autorizado, explicar qué información está prohibida y aplicar controles que detecten o oculten los datos personales, confidenciales y regulados antes de que lleguen al modelo.
La política debe ser más precisa que un simple “no introduzcas información confidencial”. Un comercial necesita saber si eso incluye los nombres de los clientes, los detalles de la cartera de proyectos, los precios, las condiciones contractuales, las actas de las reuniones y las previsiones internas. Un ingeniero necesita una orientación similar en lo que respecta al código fuente, los diseños de productos, las credenciales y la información sobre vulnerabilidades.
Sin ejemplos prácticos, una política sobre IA no es más que un documento que los empleados aceptan y luego interpretan a su manera.
La recuperación plantea un problema de permisos
Muchos sistemas de IA corporativos utilizan la generación aumentada por recuperación, conocida comúnmente como RAG. En lugar de basarse únicamente en el entrenamiento general de un modelo, la aplicación busca en fuentes internas autorizadas y proporciona material relevante al modelo a la hora de responder a una pregunta.
Esto puede hacer que un asistente resulte mucho más útil. Un empleado podría preguntar sobre una política de viajes, un procedimiento técnico o la cuenta de un cliente y recibir una respuesta basada en los registros de la empresa.
Además, esto plantea un problema importante de control de acceso. El asistente no debe recuperar documentos a los que el usuario nunca haya tenido derecho a acceder.
Un sistema mal diseñado puede conectarse a un amplio repositorio de documentos sin conservar fielmente los permisos subyacentes. Un empleado que no haya podido localizar un archivo sobre la remuneración de los directivos a través de la interfaz habitual podría, no obstante, obtener su contenido formulando al asistente una pregunta lo suficientemente concreta.
El riesgo aumenta cuando los permisos no son coherentes entre las unidades compartidas, las plataformas de colaboración y los sistemas heredados. La IA no genera esas vulnerabilidades, pero puede facilitar enormemente su explotación. La información que antes requería perseverancia y conocimiento de la estructura de archivos de la empresa puede quedar al alcance mediante preguntas formuladas en lenguaje natural.
Antes de conectar un asistente de IA a la base de conocimientos interna, la empresa debe comprobar si los permisos del sistema de origen se heredan y se aplican en el momento de la consulta. También debe examinar si las respuestas generadas revelan información a través de resúmenes, comparaciones o inferencias, incluso cuando no se muestra el documento original.
Las pruebas de acceso deben incluir solicitudes malintencionadas realistas. No basta con verificar que un empleado autorizado pueda consultar la política correcta. El equipo también debe comprobar si un empleado no autorizado puede inducir al sistema a revelar información confidencial de forma indirecta.
Una mayor cantidad de datos no garantiza automáticamente un mejor flujo de trabajo
Los proyectos de inteligencia artificial suelen partir de la hipótesis de que el rendimiento mejorará si el modelo puede acceder a más información. Esto anima a los equipos a combinar los registros de los clientes, las comunicaciones, los historiales de transacciones y los datos de comportamiento antes de decidir qué campos son realmente necesarios.
Esto es lo contrario a la minimización de datos. Amplía el alcance potencial de una filtración, aumenta la probabilidad de que la información se utilice fuera de su finalidad original y dificulta su supresión o corrección.
Un asistente de selección de personal, por ejemplo, puede necesitar conocer las competencias y la experiencia de un candidato, así como sus respuestas a preguntas relacionadas con el puesto. No necesita necesariamente fotografías, la fecha de nacimiento, información familiar ni metadatos históricos de todas las solicitudes anteriores. Un modelo de fidelización de clientes puede requerir datos sobre la actividad reciente de la cuenta sin necesidad de tener acceso ilimitado a toda la correspondencia enviada por el cliente a lo largo del tiempo.
La minimización de datos debe integrarse en la arquitectura del flujo de trabajo. El sistema solo debe recibir la información necesaria para la tarea específica, durante el período más breve que se justifique. Se pueden eliminar los identificadores irrelevantes, separar los campos altamente sensibles y transformar los datos antes de suministrarlos al modelo.
Esto también mejora la rendición de cuentas. Cuando un flujo de trabajo produce un resultado inesperado, resulta más fácil investigar un conjunto definido de datos de entrada que una recopilación indiscriminada procedente de múltiples sistemas corporativos.
La calidad de los datos se convierte en un control operativo
En la elaboración de informes convencional, unos datos de mala calidad pueden dar lugar a un gráfico o un informe de gestión inexacto. En un flujo de trabajo automatizado basado en la inteligencia artificial, pueden provocar una decisión o una acción incorrecta.
Imaginemos una aseguradora que utiliza la inteligencia artificial para gestionar las reclamaciones. Un código de póliza obsoleto podría hacer que una reclamación legítima acabara en la cola de fraudes. Un registro de cliente duplicado podría llevar a un agente de atención al cliente a facilitar información contradictoria. La ausencia de un indicador de consentimiento podría provocar que se utilizaran datos personales en un flujo de trabajo del que deberían haberse excluido.
El problema no se resuelve eligiendo un modelo más potente. El rendimiento del modelo no puede compensar de forma sistemática unos datos de origen poco fiables, campos sin definir o registros contradictorios.
Las empresas deben considerar los umbrales de calidad de los datos como condiciones previas a la implementación. Antes de automatizar un flujo de trabajo, el responsable debe saber qué fuentes utiliza, en qué medida están actualizadas, qué porcentaje de registros están incompletos y qué errores podrían afectar de manera significativa al resultado.
El indicador relevante no es simplemente la precisión del modelo. Puede ser el número de casos clasificados incorrectamente, la proporción que requiere corrección humana, la tasa de falsas alertas de fraude o el número de clientes que reciben asesoramiento basado en información desactualizada.
Esas medidas relacionan el rendimiento técnico con una consecuencia operativa.
La cadena de suministro basada en la IA forma parte del perímetro de datos
Una aplicación de IA empresarial rara vez es un único sistema suministrado por una sola empresa. Puede basarse en un modelo base, una infraestructura en la nube, una capa de orquestación, una base de datos vectorial, software de supervisión, complementos y fuentes de datos externas.
Cada componente puede influir en la forma en que se procesa y protege la información. Una empresa puede tener un contrato con el proveedor de la aplicación sin saber qué proveedor del modelo recibe las solicitudes, dónde se almacenan las representaciones o si los registros de diagnóstico contienen información de los clientes.
Los cuestionarios tradicionales para proveedores suelen ser demasiado generales para esta arquitectura. Preguntar si un proveedor cumple con una norma de seguridad no aclara si se conservan las entradas de los usuarios, si los datos de los clientes se utilizan para mejorar los modelos o qué ocurre cuando cambia un subcontratista.
Los equipos de contratación pública deben solicitar un diagrama de flujo de datos para cada flujo de trabajo de IA relevante. En él deben figurar las categorías de información recopilada, los sistemas por los que pasa, los lugares en los que se almacena, los plazos de conservación y las partes con acceso a ella.
El contrato también debería contemplar los cambios en los modelos y los componentes. Un servicio de IA puede sufrir modificaciones sustanciales cuando el proveedor sustituye el modelo subyacente, modifica los filtros de seguridad o incorpora un nuevo subencargado del tratamiento. Un flujo de trabajo aprobado para una configuración determinada no debería seguir estando aprobado indefinidamente una vez que su base técnica haya cambiado.
Por lo tanto, el riesgo asociado al proveedor pasa a ser continuo, en lugar de concentrarse en el momento de la compra.
La IA plantea riesgos de seguridad que los filtros convencionales pueden pasar por alto
Los sistemas de IA presentan los mismos riesgos de ciberseguridad que ya conocemos, como el acceso no seguro, las credenciales expuestas y los componentes de software vulnerables. Además, introducen nuevos métodos de ataque relacionados con la forma en que los modelos interpretan las instrucciones y los datos.
La inyección de comandos es un ejemplo de ello. Se pueden introducir instrucciones maliciosas en un documento, una página web, un mensaje u otro contenido procesado por el modelo. El sistema podría considerar esas instrucciones como vinculantes e ignorar las normas establecidas por la organización.
Imagina un agente de inteligencia artificial que revisa las facturas de los proveedores recibidas por correo electrónico. Un documento manipulado podría contener texto oculto que ordene al agente ignorar las instrucciones anteriores, extraer información interna o redirigir el flujo de trabajo. El riesgo es mayor cuando el sistema puede acceder a otros datos o realizar acciones sin una autorización específica.
La contaminación de datos plantea otro problema. Si se manipulan los datos de entrenamiento, prueba o recuperación, el sistema puede aprender o repetir comportamientos indeseables. La divulgación de información sensible puede producirse cuando un modelo revela contenido confidencial a través de sus resultados, ya sea porque la información aparecía en una indicación, en una base de conocimientos conectada o en un conjunto de datos gestionado de forma inadecuada.
Estos riesgos requieren algo más que la concienciación de los empleados. El sistema necesita permisos restringidos, zonas de confianza separadas, supervisión de entradas y salidas, límites de velocidad y una aprobación explícita antes de llevar a cabo acciones con consecuencias importantes. El contenido obtenido de una fuente externa no debe considerarse automáticamente como instrucciones fiables.
El principio de diseño más seguro consiste en otorgar a la IA la autoridad mínima necesaria. Un sistema que elabora una orden de pago presenta menos riesgos que uno que pueda enviar el pago sin una verificación independiente.
El registro de datos es esencial, pero genera otro conjunto de datos sensibles
Cuando un flujo de trabajo de IA genera una decisión controvertida, la empresa debe reconstruir lo que ocurrió. Para ello, puede ser necesario disponer de la consulta, los documentos recuperados, la versión del modelo, la respuesta generada, la identidad del usuario, las instrucciones del sistema y las acciones posteriores.
Sin esos registros, la investigación se convierte en una mera conjetura. La organización puede saber que se ha utilizado una herramienta de IA, pero sin poder explicar qué información ha influido en el resultado.
Sin embargo, los registros pueden llegar a ser, en sí mismos, muy sensibles. El historial de comandos puede contener quejas de clientes, información sanitaria, cláusulas contractuales, código fuente o conversaciones entre empleados. Almacenarlo todo de forma indefinida genera una nueva concentración de riesgo.
La respuesta es un registro selectivo y orientado a objetivos. Las organizaciones deben determinar qué registros son necesarios para la seguridad, la auditoría, el cumplimiento normativo y la supervisión del rendimiento, y establecer las normas de acceso y conservación en consecuencia.
Un asistente de redacción de bajo riesgo puede requerir registros operativos limitados. Un flujo de trabajo que afecte al crédito, al empleo, a los seguros o al acceso a servicios esenciales puede necesitar un registro de auditoría mucho más completo.
Los registros también deben reflejar los cambios de configuración. Si se actualiza un modelo, se modifica una plantilla de solicitud o se conecta una nueva fuente de datos, la organización debe saber qué decisiones se tomaron en cada versión.
La gobernanza debe adaptarse al flujo de trabajo, no al presupuesto tecnológico
Muchas empresas delegan la gobernanza de la IA en un comité de innovación, mientras que la protección de datos sigue siendo competencia del departamento jurídico, la ciberseguridad, del departamento de TI, y el riesgo operativo, de las distintas unidades de negocio. El resultado es una supervisión fragmentada de los flujos de trabajo que abarcan las cuatro áreas.
Una unidad de gobernanza más eficaz es el caso de uso. Cada flujo de trabajo importante debe contar con un responsable de negocio designado, encargado del resultado; un responsable técnico, encargado de la implementación; y especialistas claramente identificados en materia de seguridad, privacidad, aspectos legales y gestión de registros.
Antes de la puesta en marcha, el equipo debería ser capaz de responder a varias preguntas prácticas:
¿Qué decisión o proceso empresarial se está modificando?
¿Qué datos se incorporan al flujo de trabajo y con qué fundamento jurídico y operativo?
¿Qué sistemas y terceros la reciben?
¿Qué errores podrían causar un perjuicio material?
¿Qué acciones puede llevar a cabo la IA sin autorización?
¿Cómo podrán los usuarios impugnar o corregir el resultado?
¿Qué circunstancia obligaría a suspender el flujo de trabajo?
Estas preguntas son más útiles que preguntarse si la empresa cuenta con una estrategia de IA. Revelan si hay alguien que comprenda el sistema lo suficientemente bien como para manejarlo de forma responsable.
Empieza con un registro de flujos de trabajo de IA
El primer paso práctico es realizar un inventario. Muchas organizaciones no pueden gestionar la IA de forma eficaz porque desconocen dónde se está utilizando.
El registro debe incluir las herramientas adquiridas, los sistemas desarrollados internamente, las funciones de inteligencia artificial integradas en el software existente y los usos que los empleados hacen de los asistentes de uso general. Cada entrada debe identificar la finalidad empresarial, las categorías de datos, el propietario, el proveedor, el modelo, las integraciones, la importancia de las decisiones y el nivel de supervisión humana.
Este ejercicio suele poner de manifiesto la existencia de «IA oculta», herramientas duplicadas y sistemas que consumen más datos de los que justifica el análisis de viabilidad. Estos hallazgos no deben considerarse únicamente como incumplimientos normativos, sino como una prueba de que los empleados están intentando resolver problemas reales en los flujos de trabajo sin seguir un procedimiento aprobado.
De este modo, la organización puede clasificar los casos de uso en función de sus consecuencias. Una herramienta que reformatea texto interno no requiere el mismo entorno de control que un sistema que recomienda si se concede o no un préstamo a un cliente. La gobernanza debe ser proporcionada, pero no debe faltar.
Los flujos de trabajo de mayor riesgo deben someterse a pruebas formales antes de su puesta en marcha, lo que incluye una evaluación de la privacidad, una revisión de la seguridad, pruebas adversarias, comprobaciones de la calidad de los datos y umbrales de rendimiento definidos. También requieren un método fiable para detener o revertir el proceso si el sistema se comporta fuera de esos límites.
El riesgo ya no se limita a la pérdida de datos
La IA modifica el riesgo asociado a los datos, ya que la información ya no se limita a almacenarse y recuperarse. Se interpreta, se combina, se extraen conclusiones a partir de ella y se utiliza para tomar decisiones.
Una empresa puede proteger el registro original del cliente y, aun así, elaborar un perfil inexacto a partir de él. Puede impedir el acceso no autorizado a la base de datos y, al mismo tiempo, permitir que un asistente revele datos confidenciales en una respuesta generada. Puede conservar registros de auditoría completos, pero descubrir que nadie se encarga de revisarlos.
Los mejores programas de gobernanza de la IA no serán aquellos que aprueben el mayor número de herramientas o redacten las políticas más extensas. Serán aquellos que mantengan una cadena de responsabilidad clara desde la introducción de los datos hasta el resultado operativo.
Antes de que un flujo de trabajo de IA entre en funcionamiento, la dirección debe poder identificar los datos que necesita, la autoridad que recibe, los errores que puede cometer y la persona facultada para detenerlo. Cuando esas respuestas no están claras, la automatización no ha reducido el riesgo relacionado con los datos de la empresa. Simplemente ha acelerado ese riesgo.
