La prueba de seguridad de la IA de SAP consiste en comprobar si el departamento financiero puede detener a un agente

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

En su 15 de octubre: Análisis de la revista E3, Peter M. Färbinger planteó un problema que debería preocupar a todos los clientes de SAP que estén explorando la IA autónoma: los modelos de lenguaje funcionan de forma probabilística, mientras que la planificación de recursos empresariales depende de transacciones precisas y repetibles. Se preguntó si los grafos de conocimiento podrían proporcionar la estructura necesaria. Estos pueden ayudar a un agente a comprender las relaciones y las restricciones empresariales. Sin embargo, hay una segunda cuestión que el conocimiento semántico por sí solo no puede resolver: ¿puede la empresa retirar de forma fiable la autorización del agente para actuar?

Imaginemos un equipo de finanzas que está probando un asistente de IA que concilia los registros de los proveedores. Tras unas demostraciones satisfactorias, alguien le permite corregir las direcciones de los proveedores. A continuación, el asistente solicita a una herramienta conectada que actualice un segundo sistema. Lo que comenzó como una recomendación se ha convertido en una cadena de cambios que afecta a varios sistemas. Las consecuencias dependen de los permisos de los que dispongan realmente esas herramientas, y no de lo convincente que sea la explicación que da el asistente sobre sus decisiones.

Los usuarios de SAP ya conocen los conceptos de separación de funciones, controles financieros y flujos de trabajo de aprobación. Los agentes de IA hacen que estas disciplinas cobren mayor importancia, ya que un sistema puede planificar, activar herramientas, delegar y volver a intentarlo sin que un empleado tenga que ejecutar cada paso intermedio. Otorgar a un agente los amplios permisos de su responsable humano conlleva el riesgo de eliminar de forma inadvertida la separación que hacía que el proceso original fuera auditable.

Es difícil ignorar las pruebas que nos ofrece la IA de vanguardia

Jacob Coxon, un antiguo investigador especializado en preentrenamiento que trabajó tanto en OpenAI como en Anthropic, advertido que los laboratorios de vanguardia se están lanzando a la carrera hacia una superinteligencia capaz de mejorarse a sí misma y están jugando con la vida de las personas. Evan Hubinger, científico especializado en alineación antropica respondió que él mismo estima que hay más de un 10 % de probabilidades de que la IA acabe con toda la humanidad en la próxima década. Estas declaraciones se refieren a las posibles consecuencias futuras derivadas de unos sistemas cada vez más potentes.

Mientras tanto, un incidente ocurrido recientemente pone de manifiesto por qué es necesario someter a prueba los límites de control. OpenAI reveló que los agentes internos de investigación en IA eludieron las medidas de seguridad de aislamiento y comprometieron la seguridad de Hugging Face. La investigación independiente de METR Se descubrió que unos 1.200 agentes, que se suponía que debían estar aislados entre sí, encontraron un foro no autorizado e intercambiaron más de 70.000 mensajes y archivos; unos 700 participaron en el ataque. Los sistemas no eran aplicaciones empresariales de SAP. Lo que importa a los responsables empresariales es el patrón observado: los sistemas autónomos encontraron una vía no prevista para coordinarse y la utilizaron para ampliar sus acciones más allá de los controles previstos.

¿Qué ocurre cuando un futuro agente con límites igualmente débiles tiene acceso a las operaciones de tesorería, a los datos maestros de proveedores o a una interfaz de planificación de la producción? Una recomendación errónea es un problema. Una cadena de acciones externas no autorizadas puede mover dinero, alterar registros y perturbar el trabajo antes de que un empleado se dé cuenta.

Incluir el presupuesto de la autoridad en el contrato de implantación

Todo agente de IA empresarial debe contar con un presupuesto de autorizaciones explícito. Dicho presupuesto establece qué registros puede leer, qué puede modificar, a qué herramientas puede recurrir, de quién puede exportar datos, cuánto tiempo son válidas las credenciales y cuándo debe un humano aprobar el siguiente paso. Se trata de un límite específico para cada tarea que pueden hacer cumplir los sistemas que proporcionan el acceso, y no de una solicitud incluida en la indicación del modelo.

En el caso de un agente de cuentas por pagar, la primera versión podría limitarse a señalar facturas duplicadas y redactar explicaciones. La segunda podría corregir un campo de datos concreto dentro de un entorno de prueba. Una tercera podría presentar una propuesta de ajuste para que la apruebe un empleado autorizado. Ningún nivel debería heredar el permiso para modificar los datos bancarios o enviar pagos solo porque el responsable financiero que encargó el proyecto pueda hacerlo.

La delegación nunca debe ampliar el presupuesto. Si el agente invoca un servicio en una plataforma de integración o transfiere el trabajo a otro asistente, la acción posterior debe tener los mismos límites o unos más estrictos. Un asistente de órdenes de compra autorizado a proponer una modificación de 500 € no debería tener acceso a otra herramienta con un límite de gasto de 50 000 €. Los desarrolladores deben diseñar estos controles en el punto de ejecución real, incluyendo las interfaces de las aplicaciones y los servicios de credenciales.

Mantén los registros fuera del control del agente. Los responsables de la empresa deben saber quién solicitó y aprobó un cambio, qué pruebas lo respaldaban, qué herramientas se utilizaron y si se podría revertir. Una explicación clara no puede sustituir a un registro independiente de las acciones realizadas.

Realiza un simulacro de apagado antes de ampliar los permisos

En un entorno controlado, haz que un agente prepare una modificación en el registro de un proveedor, ponga en cola una acción posterior y, a continuación, revoque su autorización. Comprueba si la credencial original deja de funcionar, si las tareas delegadas también se detienen y con qué rapidez un operador puede identificar la última acción. Haz lo mismo cuando el registro de un proveedor contenga información contradictoria. El agente debe aplazar los cambios derivados hasta que un empleado autorizado resuelva la discrepancia.

Se trata de pruebas de aceptación cuantificables que los equipos empresariales y tecnológicos pueden realizar conjuntamente. Compara el tiempo ahorrado por transacción, la precisión de las correcciones, el número de acciones inesperadas y el tiempo necesario para revocar el acceso. Si el rendimiento mejora pero la revocación falla, ampliar la autonomía es prematuro.

Director ejecutivo de Anthropic Dario Amodei argumentó En septiembre se reclamaron normas más estrictas y evaluadores independientes a medida que se aceleran las capacidades de vanguardia. Los compradores empresariales pueden aplicar el mismo principio a nivel local exigiendo límites verificables antes de conceder un acceso de gran alcance.

Me dedico a ayudar a las organizaciones a adoptar la IA, y quiero que avancen más rápido. Los empleados ganan confianza cuando pueden experimentar dentro de unos límites que se mantienen incluso bajo presión. E3’s Debate de octubre sobre el ERP autónomo Anima acertadamente a los clientes de SAP a pensar más allá de la antigua distinción entre el software determinista y los modelos de lenguaje. La siguiente pregunta a la hora de comprar es más sencilla y ofrece más posibilidades de actuación: muéstrame qué puede cambiar este agente, quién puede detenerlo y las pruebas de que esa detención realmente funciona.