La seguridad de ERP lucha por mantenerse al ritmo de los agentes de IA

BankInfoSecurity ha llevado a Google News un conflicto incómodo: los controles de seguridad de ERP tienen dificultades para seguir el ritmo a medida que los agentes de IA adquieren autoridad operativa.

La cuestión no es si un asistente puede resumir una factura o responder una pregunta de compras. El riesgo comienza cuando un agente puede recuperar registros, invocar herramientas, modificar transacciones y coordinar acciones entre varios sistemas empresariales.

SAP, Oracle, Microsoft y Workday están orientando el software ERP hacia ese modelo. Sus agentes prometen reducir el trabajo repetitivo en finanzas, compras, recursos humanos y cadenas de suministro. Sin embargo, los controles que rodean a esos agentes aún heredan supuestos diseñados para empleados humanos y aplicaciones predecibles.

Ese desajuste crea el problema central de seguridad. La gobernanza tradicional de ERP pregunta qué persona tiene un rol y qué transacciones permite ese rol. Los sistemas agénticos introducen objetivos delegados, contexto cambiante, selección de herramientas y transferencias de máquina a máquina.

Un agente puede contar con credenciales válidas y aun así realizar una acción insegura. También puede combinar varios pasos permitidos individualmente en un resultado que ningún administrador pretendía.

Los proveedores de ERP están incorporando controles de identidad, puntos de aprobación y funciones de auditoría. Estas medidas importan, pero no eliminan el conflicto más profundo entre la autonomía de los agentes y los controles empresariales deterministas.

La advertencia de Google News trata sobre autoridad, no sobre chatbots

El cambio importante es que los agentes de IA para ERP están pasando de leer datos empresariales a actuar sobre ellos.

El informe sobre seguridad de ERP difundido a través de Google News plantea el problema como una carrera entre la expansión de las capacidades de los agentes y una adaptación de la seguridad más lenta.

Ese planteamiento importa porque los sistemas ERP contienen la verdad operativa de una empresa. Almacenan instrucciones de pago, registros de empleados, condiciones de proveedores, posiciones de inventario, saldos de clientes y aprobaciones financieras.

Un chatbot convencional puede generar una respuesta incorrecta. Un agente de ERP con derechos de ejecución puede convertir una respuesta incorrecta en un asiento contable registrado o un cambio de proveedor aprobado.

La IA agéntica se refiere a software capaz de interpretar un objetivo, crear un plan, elegir herramientas y realizar varios pasos con supervisión limitada. Esto difiere de la automatización fija, que sigue una ruta predefinida.

Un flujo de trabajo tradicional podría rechazar una factura siempre que falte una orden de compra. Un agente puede investigar la discrepancia, recuperar correspondencia, comparar registros de entrega y recomendar una excepción.

Esa flexibilidad crea valor porque los procesos empresariales reales contienen ambigüedad. También debilita la previsibilidad de la que dependen muchos controles de seguridad existentes.

Los equipos de seguridad pueden examinar un flujo de trabajo fijo antes de su implementación. Saben qué campos lee, qué llamadas al sistema realiza y qué condiciones activan una aprobación.

Un agente puede elegir una secuencia distinta cada vez. Su comportamiento puede cambiar según el prompt, las herramientas disponibles, los documentos recuperados, la versión del modelo o la conversación circundante.

Eso significa que la autorización no puede detenerse en el inicio de sesión. La seguridad debe evaluar la identidad del agente, el propósito delegado, el contexto actual, la herramienta seleccionada, los datos solicitados y el efecto previsto.

El problema se vuelve más difícil cuando un agente cruza los límites entre aplicaciones. Un agente financiero puede consultar correo electrónico, registros de compras, datos de clientes y un sistema de pagos antes de completar una tarea.

Cada conexión amplía la superficie de ataque. También hace más difícil asignar responsabilidades cuando varios componentes contribuyen a un resultado inseguro.

Los lectores de Google News podrían interpretar inicialmente la historia como otra advertencia sobre la precisión de la IA generativa. El problema subyacente es más trascendental.

Los equipos de seguridad de ERP deben gobernar software que se comporta menos como una aplicación pasiva y más como un trabajador altamente conectado. Ese trabajador puede operar de forma continua, a velocidad de máquina y entre límites organizativos.

El cambio presiona a responsables de seguridad de la información, administradores de ERP, equipos de identidad, auditores internos y propietarios de procesos empresariales. Ninguno de esos grupos puede gestionar el riesgo por sí solo.

Los equipos de seguridad entienden el control de acceso, pero pueden carecer de un contexto detallado de los procesos. Los responsables financieros entienden las consecuencias materiales, pero quizá no vean cada dependencia técnica.

Los administradores de ERP entienden los roles y las transacciones. Puede que no controlen los modelos externos, los marcos de agentes ni las herramientas de terceros conectadas al flujo de trabajo.

Por tanto, el desafío inmediato es organizativo además de técnico. Las empresas necesitan un modelo de control que siga a un agente desde la instrucción inicial hasta cada acción resultante.

Los agentes de IA para ERP rompen el modelo de identidad humana

Una identidad válida ya no demuestra que una acción sea apropiada cuando el software puede reinterpretar objetivos y elegir su propia ruta de ejecución.

Los controles de ERP se han centrado tradicionalmente en usuarios identificados, roles asignados y segregación de funciones. La segregación de funciones impide que una sola persona controle etapas incompatibles de un proceso sensible.

Por ejemplo, el empleado que crea un proveedor no debería aprobar de forma independiente los pagos a ese proveedor. La regla limita el fraude y reduce el impacto de credenciales comprometidas.

Los agentes complican este modelo porque la autoridad puede pasar por varias capas. Una persona instruye a un agente, el agente llama a otro agente y ese agente invoca una aplicación empresarial.

El sistema final puede ver únicamente una identidad de servicio autenticada. Puede que no reciba el usuario original, el propósito, la evidencia o los límites vinculados a la solicitud.

Esto crea un problema de cadena de delegación. Cada sistema reconoce a su llamante inmediato, mientras que la fuente completa y la intención de la acción se vuelven más difíciles de reconstruir.

Las credenciales compartidas de agentes agravan el problema. Si varios flujos de trabajo utilizan una cuenta de servicio, los investigadores pueden tener dificultades para distinguir la automatización legítima del uso indebido.

Las credenciales persistentes también permiten que la autoridad sobreviva a su propósito original. Un agente creado para un proyecto temporal de conciliación podría conservar acceso después de que ese trabajo termine.

Las revisiones de acceso humano suelen operar en torno a eventos laborales y roles fijos. Los agentes pueden aparecer, cambiar, duplicarse y desaparecer mucho más rápido que los empleados.

También pueden ensamblarse fuera de los procesos formales de desarrollo. Un equipo empresarial puede conectar un modelo a una herramienta aprobada sin reconocer que esa combinación crea una nueva identidad privilegiada.

El marco de seguridad agéntica de OWASP identifica el abuso de identidad y privilegios entre sus riesgos centrales. También destaca el secuestro de objetivos, el uso indebido de herramientas y las debilidades de la cadena de suministro agéntica.

El secuestro de objetivos ocurre cuando contenido malicioso o no confiable cambia lo que un agente intenta lograr. La instrucción dañina puede estar dentro de un documento, mensaje, página web o respuesta de una herramienta.

Esto es más peligroso dentro de ERP que en un asistente independiente. El agente puede ya disponer de acceso a registros confidenciales y funciones de transacción.

Pensemos en un agente de compras que lee correos electrónicos de proveedores. Un mensaje comprometido podría instruir al modelo para priorizar una cuenta bancaria controlada por un atacante o revelar datos internos de compras.

La solicitud podría entrar en conflicto con el objetivo original del usuario. Sin embargo, el agente podría tratar el texto incrustado como contexto operativo relevante a menos que las salvaguardas separen los datos de las instrucciones.

El principio de mínimo privilegio sigue siendo necesario, pero su implementación debe ser más precisa. Un agente debería recibir únicamente los permisos necesarios para un propósito y un período limitados.

La guía de operaciones seguras de Oracle deja explícita esta distinción. Un agente de análisis no necesita derechos de aprobación de compras simplemente porque ambos participan en un mismo flujo de trabajo.

El principio parece conocido, pero los agentes dificultan más su aplicación. Sus planes pueden evolucionar después de que comienza una tarea, y pueden solicitar herramientas adicionales durante la ejecución.

Los roles estáticos no pueden expresar por completo condiciones como el propósito, el valor de la transacción, la sensibilidad de los datos, la confianza o si otro agente inició la solicitud.

Por ello, las empresas necesitan verificaciones de políticas en el momento de la acción. Esas verificaciones deberían evaluar tanto la operación solicitada como el contexto que la rodea.

Las acciones de alto impacto también requieren pruebas más sólidas de la intención humana. Un botón de confirmación es insuficiente si el revisor solo ve un resumen pulido producido por el mismo agente.

El revisor necesita la evidencia original, los cambios propuestos, las excepciones de política y el efecto empresarial esperado. De lo contrario, la supervisión humana se vuelve ceremonial.

La verdadera disyuntiva es autonomía frente a control

Cada aumento de la autonomía de los agentes eleva la exigencia sobre identidad, aplicación de políticas, observabilidad y recuperación.

Los agentes de IA para ERP se vuelven útiles cuando pueden gestionar excepciones. Sin embargo, las excepciones son precisamente donde los controles deterministas ofrecen menos cobertura.

Una automatización fija sigue rutas que los desarrolladores definen de antemano. Un agente interpreta información incompleta y decide qué ruta parece apropiada.

Esta distinción crea una disyuntiva de seguridad. Si se restringe demasiado a un agente, se convierte en una interfaz costosa para flujos de trabajo existentes. Si se le concede mayor autoridad, sus errores adquieren consecuencias operativas.

El conflicto no desaparece cuando un agente permanece dentro de la nube de un proveedor. Un entorno controlado puede reducir la exposición, pero la lógica empresarial sigue determinando si una acción es aceptable.

Un agente puede tener permiso para actualizar registros de proveedores. Ese permiso no significa que cada actualización de proveedor responda a un propósito legítimo.

Un agente también puede combinar capacidades de bajo riesgo en una secuencia de alto riesgo. Leer facturas, crear proveedores y preparar pagos parecen manejables cuando se evalúan por separado.

Juntas, esas capacidades pueden reproducir una ruta completa de fraude. Esto a veces se denomina riesgo composicional, donde componentes que parecen seguros producen un resultado combinado inseguro.

Las herramientas de seguridad suelen inspeccionar llamadas individuales a API. Pueden aprobar cada paso sin detectar el plan más amplio que los conecta.

La memoria de los agentes crea otra dificultad. La memoria permite al software conservar contexto de tareas, preferencias u observaciones previas entre interacciones.

Esa continuidad puede mejorar el rendimiento. También puede conservar instrucciones maliciosas, datos sensibles o supuestos incorrectos más allá de la sesión en la que entraron al sistema.

La generación aumentada por recuperación, o RAG, proporciona a un modelo información empresarial seleccionada al responder o actuar. Su seguridad depende de la fuente, los permisos, la calidad y la actualidad del material recuperado.

Una fuente de conocimiento contaminada puede distorsionar decisiones posteriores sin comprometer directamente el modelo subyacente. Un documento de políticas desactualizado puede producir un resultado similar mediante un fallo operativo ordinario.

Esto convierte la gobernanza de la información en parte de la seguridad de los agentes de IA. Los equipos deben saber qué fuentes utiliza un agente, quién puede modificarlas y cómo la evidencia recuperada afecta las decisiones.

Los empleados que desarrollan flujos de trabajo internos también necesitan documentación fiable. Una base de conocimientos con capacidad de búsqueda puede ayudar a los equipos a conservar decisiones de diseño, modelos de amenazas y requisitos de aprobación relacionados con los despliegues de agentes.

La documentación no puede sustituir a los controles técnicos. Puede reducir la probabilidad de que supuestos críticos desaparezcan cuando un agente cambia de responsable o pasa de una fase piloto a producción.

El acceso a herramientas crea un riesgo paralelo. Las herramientas traducen la salida del modelo en acciones, como consultar una base de datos, enviar un mensaje o modificar un registro empresarial.

El modelo no necesita credenciales directas de la base de datos si una herramienta conectada ya las posee. Por tanto, la herramienta pasa a formar parte del límite efectivo de permisos del agente.

Las revisiones de seguridad deben examinar los esquemas de las herramientas, la validación de entradas, el almacenamiento de credenciales, el filtrado de salidas y el comportamiento ante fallos. Revisar únicamente el modelo omite gran parte de la ruta de ejecución.

Los sistemas multiagente aumentan aún más la incertidumbre. Un agente puede delegar la investigación, otro puede interpretar la política y un tercero puede ejecutar la transacción.

En cada transferencia puede perderse contexto o introducirse una salida no fiable. También puede ocultarse qué componente tomó la decisión que causó el daño.

La arquitectura de seguridad publicada por SAP rastrea las solicitudes de los agentes a través de la verificación de identidad, el procesamiento de IA, la ejecución empresarial y el registro forense.

Esa visión integral va en la dirección correcta. Sin embargo, los diagramas de arquitectura no demuestran que todos los despliegues de clientes apliquen los controles de forma coherente.

Los entornos ERP contienen código personalizado, integraciones heredadas, sistemas adquiridos, socios externos y excepciones de larga duración. Esas diferencias pueden debilitar el modelo de seguridad predeterminado de un proveedor.

Los despliegues más difíciles involucrarán entornos híbridos. Un agente puede comenzar en un servicio moderno en la nube, pero actuar a través de aplicaciones antiguas con permisos amplios y telemetría limitada.

En esos entornos, el componente más reciente puede heredar el control más débil de la cadena. La autonomía de los agentes amplifica entonces la deuda técnica que las organizaciones ya tenían dificultades para gestionar.

Los registros de auditoría no pueden explicar todas las decisiones de los agentes

La seguridad de los ERP necesita evidencias que conecten la intención del usuario con el razonamiento del agente, las llamadas a herramientas, los cambios en los datos y los resultados empresariales.

Los registros de auditoría tradicionales responden a preguntas conocidas. Muestran qué cuenta accedió a un sistema, cuándo se produjo una transacción y qué campo cambió.

Los flujos de trabajo agénticos exigen una cadena de evidencias más larga. Los investigadores necesitan conocer el usuario iniciador, el objetivo delegado, la versión del modelo, el contexto recuperado, las decisiones de política, las llamadas a herramientas y el resultado final.

También pueden necesitar saber qué se negó a hacer el agente. Las solicitudes denegadas repetidas pueden revelar intentos de sondeo, configuraciones erróneas o una fuente comprometida.

Registrar cada prompt y respuesta no es una solución sencilla. Los prompts pueden contener registros de nóminas, contratos, datos personales, credenciales y otra información restringida.

Por tanto, un registro completo puede crear otro repositorio sensible. Las reglas de retención, acceso, cifrado y ocultación de datos deben corresponderse con los datos empresariales subyacentes.

El razonamiento del modelo plantea otra complicación. Una explicación generada puede sonar coherente sin representar con precisión cómo el sistema llegó a su resultado.

Los equipos de seguridad no deben tratar una explicación narrativa como prueba. Necesitan registros verificables de entradas, solicitudes de herramientas, evaluaciones de políticas y cambios de estado resultantes.

Esto cambia el significado de la observabilidad. La monitorización debe capturar el comportamiento en todo el flujo de trabajo, no solo la disponibilidad del modelo o los errores de API.

Entre las señales útiles se incluyen la selección inesperada de herramientas, un volumen inusual de transacciones, accesos fuera del ámbito habitual de negocio, denegaciones repetidas de políticas y cambios en registros sensibles.

Las líneas de base también deben reflejar la finalidad asignada al agente. Un agente de conciliación de nóminas y un agente de aprovisionamiento no deberían compartir el mismo perfil de comportamiento normal.

Los límites de velocidad pueden reducir el radio de impacto de los errores. No pueden determinar si un pequeño número de acciones de alto valor es legítimo.

Los umbrales de transacción aportan otra capa. Sin embargo, los atacantes pueden dividir la actividad en acciones más pequeñas o explotar procesos en los que un cambio de bajo valor posibilita una pérdida posterior.

Las empresas necesitan controles en varios puntos. El entorno de ejecución del agente debe restringir las herramientas, la capa de identidad debe restringir la autoridad y el ERP debe validar las reglas de negocio.

La monitorización independiente debe verificar después lo que realmente ocurrió. Confiar en el mismo agente para actuar, evaluar e informar sobre su propio comportamiento concentra demasiada confianza.

La aprobación humana sigue siendo valiosa para acciones irreversibles o materiales. Sin embargo, los revisores necesitan suficiente tiempo y contexto para detectar manipulaciones.

La fatiga de aprobación puede convertir una salvaguarda en una formalidad. Los agentes que operan a velocidad de máquina pueden generar más solicitudes de revisión de las que los empleados pueden evaluar con atención.

La autonomía escalonada según el riesgo ofrece un modelo más viable. Las tareas reversibles y de bajo impacto pueden avanzar automáticamente, mientras que las acciones sensibles requieren validación independiente.

Entre los ejemplos de trabajo de menor riesgo se incluyen redactar explicaciones, recopilar evidencias y señalar anomalías. El trabajo de mayor riesgo incluye cambiar datos de pago, liberar fondos o modificar accesos.

La reversibilidad debería influir en el nivel de control. Un informe erróneo puede corregirse, mientras que un pago externo o un registro eliminado pueden causar daños duraderos.

El perfil de riesgo de NIST organiza el trabajo sobre riesgos de IA en torno a la gobernanza, el mapeo, la medición y la gestión. Ese enfoque de ciclo de vida encaja mejor con los agentes ERP que una aprobación puntual.

El riesgo de un agente cambia cuando cambian sus herramientas, modelo, fuentes de datos, permisos o propósito empresarial. Cada modificación debe desencadenar una reevaluación y pruebas específicas.

Las pruebas deben incluir entradas adversarias y excepciones empresariales realistas. Una demostración basada en datos limpios no revelará cómo se comporta un agente ante instrucciones contradictorias.

Los equipos también deben probar fallos parciales. Un sistema posterior puede agotar el tiempo de espera después de que un agente complete un paso, pero antes de registrar el siguiente.

Sin idempotencia, que evita que la ejecución repetida produzca efectos duplicados, un agente puede enviar la misma transacción de nuevo durante la recuperación.

Estos problemas ordinarios de fiabilidad se convierten en cuestiones de seguridad cuando afectan a registros financieros, derechos de acceso o datos regulados. La seguridad de los agentes no puede permanecer separada de la ingeniería de sistemas.

Las salvaguardas de los proveedores se enfrentan a la realidad de los ERP personalizados

SAP y Oracle pueden proteger sus propias plataformas de agentes, pero los clientes siguen controlando las integraciones, los roles, los datos y las excepciones que determinan el riesgo práctico.

Los proveedores de ERP tienen una ventaja estructural. Entienden sus modelos de aplicación y pueden integrar agentes junto a los servicios existentes de identidad, flujos de trabajo y auditoría.

Los agentes nativos pueden heredar metadatos empresariales que un modelo externo no tiene. También pueden utilizar interfaces aprobadas en lugar de imitar acciones de usuario a través de una pantalla.

Oracle aconseja a los clientes separar las responsabilidades de los agentes y aplicar el principio de mínimo privilegio entre agentes que cooperan. SAP describe comprobaciones de identidad, aislamiento de inquilinos, validación de salidas y pistas de auditoría forense.

Esos controles abordan preocupaciones reales. También respaldan el argumento de los proveedores de que los agentes integrados son más seguros que la automatización de terceros conectada de forma laxa.

El argumento tiene límites. La mayoría de las grandes organizaciones no opera un único entorno ERP limpio con configuraciones estándar.

Ejecutan procesos personalizados en varios sistemas. Algunas aplicaciones permanecen en las instalaciones, mientras que otras se alojan en nubes públicas o servicios gestionados por proveedores.

Socios, contratistas, bancos, proveedores logísticos y unidades de negocio adquiridas pueden conectarse al mismo proceso. Cada límite introduce un modelo distinto de identidad y control.

Un agente financiero nativo puede seguir recibiendo contenido no fiable desde el correo electrónico. Puede depender de un analizador de documentos de terceros o enviar un resultado a una aplicación de pagos más antigua.

La fiabilidad del flujo de trabajo completo depende de esas dependencias. La documentación de seguridad del proveedor no puede tener en cuenta todas las extensiones de cada cliente.

Los agentes externos presentan una disyuntiva diferente. Pueden coordinar el trabajo entre plataformas de ERP, CRM, comunicaciones y analítica que compiten entre sí.

Esa independencia puede reducir la dependencia de un proveedor y respaldar flujos de trabajo más amplios. También introduce otra identidad, capa de orquestación y ecosistema de herramientas entre los usuarios y los registros empresariales.

Por tanto, la elección práctica no es entre software nativo seguro y software externo inseguro. Ambos enfoques crean riesgos, pero concentran esos riesgos en lugares distintos.

Los agentes nativos concentran la confianza en la plataforma, la nube y el modelo de gobernanza del proveedor de ERP. Los agentes externos distribuyen la confianza entre conectores, credenciales, modelos y herramientas de orquestación.

Los equipos de seguridad deben evaluar la ruta completa de acción en lugar de aceptar etiquetas por categoría. Un producto nativo puede volverse inseguro mediante una configuración demasiado amplia.

Un producto externo puede reducir el riesgo si recibe autoridad de alcance limitado y corta duración, y no puede completar directamente transacciones sensibles.

Las revisiones de compras deben reflejar estas diferencias. Los cuestionarios estándar sobre software rara vez capturan la profundidad de la delegación, el comportamiento de la memoria, el manejo de prompts o los permisos a nivel de herramienta.

Los compradores deben preguntar qué identidad aparece en el registro del ERP y si identifica al usuario original. También deben preguntar cómo sigue la política a una tarea a través de las transferencias entre agentes.

Otras preguntas esenciales se refieren a las actualizaciones del modelo, el contexto conservado, la residencia de datos, la respuesta a incidentes y el acceso del cliente a telemetría detallada.

El proveedor debe explicar cómo los administradores pueden suspender inmediatamente a un agente. Ese control debe revocar las credenciales activas e interrumpir las acciones pendientes, no limitarse a ocultar la interfaz.

Los clientes también necesitan evidencias sobre la gestión de cambios. El comportamiento de un agente puede cambiar después de modificar un modelo, el prompt del sistema, la definición de una herramienta o una fuente de recuperación.

Una actualización de aplicación tradicional suele modificar código determinista. Una actualización de modelo puede alterar decisiones incluso cuando el flujo de trabajo circundante permanece sin cambios.

Por tanto, las pruebas de seguridad deben continuar después del despliegue. Los equipos deben ejecutar tareas representativas y casos de abuso cada vez que cambie un componente significativo.

Deben comparar los resultados entre versiones y conservar suficientes evidencias para investigar regresiones. Una prueba superada hace seis meses dice poco sobre un agente modificado.

La presión competitiva puede socavar esta disciplina. Los proveedores de ERP quieren que los clientes adopten agentes, mientras que los líderes empresariales quieren mejoras medibles de productividad.

Los equipos de seguridad pueden recibir presión para aprobar proyectos piloto amplios antes de que los sistemas de identidad y monitorización estén preparados. Esa secuencia convierte la gobernanza en un proyecto de reparación.

Un despliegue más seguro comienza con tareas acotadas y resultados observables. La autoridad se amplía solo después de que la organización pueda explicar, detectar y revertir el comportamiento del agente.

Tres señales mostrarán si la seguridad de los ERP se pone al día

La próxima fase estará determinada por identidades específicas para agentes, aplicación de controles a nivel de acción y evidencias de incidentes reales en producción.

La primera señal es si las plataformas ERP adoptan identidades distintas y de corta duración para cada agente y tarea delegada. Las cuentas de servicio compartidas deberían convertirse en una excepción.

Un diseño maduro preservará al usuario original, la identidad del agente, el propósito y la autoridad durante todo el flujo de trabajo. Las aplicaciones posteriores deberían recibir ese contexto antes de permitir una acción.

Esto reforzaría el argumento de que los agentes de IA para ERP pueden operar dentro de estructuras establecidas de rendición de cuentas. La dependencia continua de credenciales amplias lo debilitaría.

La segunda señal es si proveedores y clientes aplican políticas a nivel de transacción. El permiso para usar una herramienta no debe convertirse en permiso para cualquier resultado posible de esa herramienta.

Los controles deben considerar el tipo de transacción, el valor, el destino, la evidencia de origen y la reversibilidad. Las operaciones sensibles deben requerir verificaciones independientes fuera del modelo que actúa.

Los equipos de seguridad deben vigilar los lanzamientos de productos en busca de funciones concretas de aplicación. El lenguaje de marketing sobre IA responsable es menos útil que los controles configurables y los registros exportables.

También deben examinar si esos controles funcionan entre aplicaciones conectadas. Una protección limitada a la interfaz de un proveedor no cubrirá un flujo de trabajo multiplataforma.

La tercera señal es la calidad de los informes públicos sobre incidentes. Los fallos en producción revelarán dónde las arquitecturas teóricas se rompen bajo condiciones empresariales reales.

Las divulgaciones útiles identificarán la identidad comprometida, la entrada manipulada, las herramientas afectadas, las acciones no autorizadas y el método de contención. Las referencias vagas a un error de IA no ayudarán a los defensores.

Los incidentes también deben aclarar si existía aprobación humana y por qué falló. Esa evidencia mostrará si la supervisión reduce el riesgo o simplemente transfiere la responsabilidad.

La afirmación central detrás de la advertencia de Google News cobrará fuerza si los agentes se expanden más rápido que esos tres controles. Se debilitará si identidad, aplicación y evidencia maduran conjuntamente.

Las organizaciones no deben esperar una pérdida importante antes de mapear su propia exposición. Pueden comenzar enumerando cada agente conectado a un proceso de ERP.

Ese inventario debe incluir propietario, propósito, modelo, herramientas, fuentes de datos, credenciales, puntos de aprobación y procedimiento de apagado. Las entradas desconocidas merecen una investigación inmediata.

A continuación, los equipos deben rastrear algunos flujos de trabajo de alto impacto, desde la instrucción hasta la transacción final. Los cambios de pagos, las concesiones de acceso, los asientos contables y las actualizaciones de registros de empleados son buenos puntos de partida.

El ejercicio expondrá el contexto faltante entre sistemas. También revelará dónde una credencial o herramienta posee más autoridad de la que requiere la tarea empresarial.

Luego, las empresas deben clasificar las acciones según su impacto y reversibilidad. La investigación de solo lectura no necesita los mismos controles que liberar fondos o modificar datos maestros.

Por último, los líderes de seguridad deben probar cómo responde la organización cuando un agente se comporta incorrectamente. La detección sin contención deja sin responder la pregunta más importante.

¿Pueden los administradores detener al agente, revocar su autoridad, conservar evidencia, revertir la acción e identificar los registros afectados antes de que el daño se extienda?

La seguridad de ERP no necesita eliminar la autonomía. Necesita garantizar que la autonomía nunca se convierta en autoridad sin límites.

El siguiente paso práctico es sencillo: elija un flujo de trabajo de agente activo o planificado y rastree cada identidad, herramienta, fuente de datos y aprobación que utiliza. Si su equipo no puede explicar esa cadena, el agente no está listo para un acceso más amplio.

Pregunte quién puede detenerlo, qué evidencia permanece y qué acciones pueden revertirse. Esas respuestas importan más que otra demostración pulida.

Google News ha puesto sobre la mesa la advertencia. Ahora los equipos empresariales deben decidir si sus controles de ERP gobiernan a los agentes con el mismo cuidado con el que gobiernan a las personas.