La prueba de seguridad de IA de SAP: ¿puede el departamento financiero detener a un agente de IA?

Está leyendo la traducción al alemán de este artículo. Puede consultar la versión original en inglés aquí.

En su Editorial de la revista E3 del 15 de octubre Peter M. Färbinger planteó un problema que debería preocupar a cualquier cliente de SAP que se ocupe de la IA autónoma. Los modelos de lenguaje funcionan de forma probabilística, mientras que la planificación de recursos empresariales (ERP) se basa en transacciones precisas y reproducibles. Se preguntó si los grafos de conocimiento podrían proporcionar la estructura necesaria para ello. De hecho, pueden ayudar a un agente a comprender las relaciones empresariales y las condiciones marco. Sin embargo, hay una segunda pregunta que no puede responderse únicamente con conocimiento semántico: ¿puede una empresa retirar de forma fiable la autorización para actuar a un agente de IA?

Imaginemos un equipo financiero que está probando un asistente de IA para cotejar los datos maestros de los proveedores. Tras unas demostraciones satisfactorias, el asistente recibe autorización para corregir las direcciones de los proveedores. A continuación, a través de una herramienta conectada, ordena la actualización de un segundo sistema. Lo que comenzó como una recomendación se ha convertido en una cadena de cambios que abarca varios sistemas. Las consecuencias que esto tenga dependerán de los permisos reales de las herramientas utilizadas, y no de lo convincente que sea el asistente a la hora de justificar sus decisiones.

Los usuarios de SAP ya están familiarizados con la separación de funciones, los controles financieros y los flujos de trabajo de autorización. Los agentes de IA hacen que estos mecanismos de control cobren aún más importancia, ya que un único sistema puede planificar de forma autónoma, acceder a herramientas, delegar tareas y reintentar acciones sin que un empleado tenga que realizar cada uno de los pasos intermedios. Si un agente recibe los mismos permisos amplios que su responsable humano, existe el riesgo de que se eluda, sin que nadie se dé cuenta, precisamente esa separación de funciones que hacía que el proceso original fuera trazable y verificable.

Es casi imposible ignorar las señales de alerta que nos envía el desarrollo de la IA más avanzada

Jacob Coxon, un antiguo investigador en el ámbito del preentrenamiento de modelos de IA que trabajó tanto en OpenAI como en Anthropic, advirtió, que los principales laboratorios de IA se encuentran inmersos en una carrera por crear una superinteligencia capaz de mejorarse a sí misma, poniendo en peligro vidas humanas. Evan Hubinger, investigador en alineación en Anthropic, respondió, que estima personalmente que la probabilidad de que la IA pueda acabar con toda la humanidad en los próximos diez años es superior al diez por ciento. Estas afirmaciones se refieren a las posibles consecuencias futuras de unos sistemas de IA cada vez más potentes.

Mientras tanto, un incidente reciente pone de manifiesto por qué es necesario comprobar en la práctica los límites de los mecanismos de control. OpenAI lo hizo público, que unos agentes internos de investigación en IA habían eludido los mecanismos de aislamiento y habían comprometido la plataforma Hugging Face. Una Investigación independiente de METR Se descubrió que unos 1.200 agentes, que en principio debían estar aislados entre sí, encontraron un foro de mensajes no autorizado y, a través de él, intercambiaron más de 70.000 mensajes y archivos. Unos 700 agentes participaron en el ataque. Estos sistemas no eran aplicaciones SAP de gestión empresarial. Sin embargo, para los responsables de las empresas, lo decisivo es el patrón de comportamiento demostrado: los sistemas autónomos encontraron una vía involuntaria de coordinación y la utilizaron para ampliar sus actividades más allá de los límites de control previstos.

¿Qué ocurriría si un futuro agente de IA, con limitaciones igualmente insuficientes, tuviera acceso a los procesos de tesorería, a los datos maestros de proveedores o a las interfaces de planificación de la producción? Una recomendación errónea es una cosa. Sin embargo, una cadena de acciones no autorizadas en sistemas externos puede mover dinero, modificar registros de datos y perturbar los procesos operativos antes de que ningún empleado se dé cuenta de nada.

Convertir el marco de autorizaciones en un elemento vinculante de la implantación de la IA

Cada agente de IA utilizado en el ámbito empresarial debería disponer de un presupuesto de permisos claramente definido. Este presupuesto establece qué conjuntos de datos puede consultar el agente, qué modificaciones puede realizar, a qué herramientas puede acceder, qué datos puede exportar, cuánto tiempo son válidas sus credenciales de acceso y cuándo debe un ser humano autorizar el siguiente paso. Se trata de una restricción relacionada con las tareas que debe ser aplicada técnicamente por los sistemas que conceden el acceso, y no solo de una instrucción en el mensaje del modelo de lenguaje.

En el caso de un agente de IA para la contabilidad de acreedores, la primera fase de desarrollo podría consistir exclusivamente en señalar las facturas duplicadas y redactar explicaciones. En una segunda fase, podría corregir un campo de datos claramente definido dentro de un entorno de prueba. Una tercera fase podría permitirle presentar una propuesta de corrección para que la apruebe un empleado autorizado. Ninguna de estas fases debería recibir automáticamente la autorización para modificar datos bancarios o iniciar pagos, solo porque el directivo del departamento financiero que haya encargado el proyecto esté autorizado a hacerlo.

El presupuesto de autorizaciones tampoco debe aumentar nunca, incluso cuando se delegan tareas. Si un agente accede a un servicio en una plataforma de integración o transfiere tareas a otro asistente, deben aplicarse las mismas restricciones, o incluso más estrictas, a las acciones posteriores. Un asistente de pedidos que solo pueda proponer una modificación por valor de 500 euros no debe poder acceder de repente, a través de otra herramienta, a un límite de gasto de 50 000 euros. Los desarrolladores deben implementar estas comprobaciones allí donde se ejecutan realmente las acciones, incluidas las interfaces de las aplicaciones y los servicios de gestión de credenciales.

Los datos de registro deben permanecer fuera del control del agente. Los responsables del proceso deben poder rastrear quién solicitó y autorizó un cambio, en qué información se basó, qué herramientas se utilizaron y si el cambio puede revertirse. Una explicación convincente desde el punto de vista lingüístico no puede sustituir a un registro de acciones llevado de forma independiente.

Realizar una prueba de desconexión antes de ampliar los permisos

En un entorno controlado, un agente debería, en primer lugar, preparar una modificación en un registro maestro de proveedor y poner en cola una acción posterior. A continuación, se le retiran sus permisos. En este proceso, hay que evaluar si los datos de acceso originales dejan de ser válidos, si también se detienen las tareas delegadas y con qué rapidez puede identificar un empleado responsable la última acción realizada. Debería realizarse la misma prueba cuando un registro maestro de proveedor contenga información contradictoria. El agente debe posponer los cambios que puedan tener repercusiones significativas hasta que un empleado autorizado haya aclarado las discrepancias.

Se trata de pruebas de aceptación cuantificables que los departamentos especializados y los equipos de TI pueden llevar a cabo conjuntamente. Se deben comparar el ahorro de tiempo por transacción, la precisión de las correcciones, el número de acciones inesperadas y el tiempo necesario para revocar los permisos. Aunque mejore el rendimiento del agente, si la retirada de permisos no funciona de forma fiable, es prematuro ampliar su autonomía.

Director general de Anthropic Dario Amodei abogó por En septiembre, ante el rápido avance de los sistemas de IA de alto rendimiento, se abogó por normas más estrictas y organismos de control independientes. Las empresas pueden aplicar este mismo principio a sus propios proyectos de IA exigiendo límites de eficacia demostrada antes de conceder a los agentes amplias capacidades de actuación.

Ayudo profesionalmente a las empresas a implantar la IA y quiero que avancen más rápido. Los empleados ganan confianza cuando pueden experimentar dentro de unas normas claras que funcionan de forma fiable incluso bajo presión. La Debate de E3 celebrado en octubre sobre el ERP autónomo Insta, con razón, a los clientes de SAP a ir más allá de la distinción tradicional entre software determinista y modelos de lenguaje. La siguiente pregunta clave a la hora de adquirir este tipo de soluciones es más sencilla y más práctica: muéstreme qué puede modificar este agente, quién puede detenerlo y qué pruebas demuestran que esa detención funciona realmente.