Agentes AI para el back office del mercado medio: controles antes de la automatización

1. Definir la decisión del consejo como autoridad delegada

Un agente de AI debe tratarse como una capacidad operativa delegada. La decisión del consejo de administración se refiere a qué objetivos puede perseguir el sistema, qué información puede utilizar, qué herramientas puede invocar, qué compromisos puede crear y qué acciones siguen sujetas a aprobación. Una licencia para usar un modelo o una demostración exitosa no responde a esas preguntas.

El caso económico puede resultar atractivo. Las funciones de back office contienen búsquedas repetidas, conciliaciones, gestión de documentos, triaje de excepciones, seguimientos y actualizaciones de estado. Un agente puede conectar estos pasos entre sistemas y a lo largo del tiempo. Puede preparar un paquete de alta de proveedores, rastrear una factura en disputa, elaborar una previsión de tesorería o coordinar un caso de atención al cliente. El valor surge cuando la empresa elimina demoras, retrabajos y responsabilidad fragmentada, preservando al mismo tiempo evidencia fiable.

La exposición en materia de control también se amplía. El agente puede seleccionar el registro incorrecto, seguir una instrucción incrustada en un documento no fiable, usar una credencial más allá del propósito previsto, divulgar datos personales, crear un pago duplicado, aplicar una política obsoleta o continuar después de que el contexto de negocio haya cambiado. La consecuencia puede recorrer varios sistemas antes de que una persona la vea.

El mandato del consejo de administración debe definir, por tanto, cuatro límites. El límite de resultados establece qué puede lograr el agente. El límite de recursos establece qué datos, aplicaciones, identidades, presupuesto y tiempo puede utilizar. El límite de acciones establece qué actos puede ejecutar y cuáles requieren aprobación. El límite de fallos establece cómo se detiene el sistema, contiene el daño, preserva la evidencia y devuelve el trabajo a una persona.

La primera decisión de política debe identificar las acciones prohibidas. Los ejemplos pueden incluir liberar efectivo, cambiar datos bancarios, poner fin a una relación laboral, aceptar responsabilidad contractual, presentar declaraciones regulatorias, saltarse la segregación de funciones o comunicar a una persona una decisión adversa definitiva. La lista exacta depende de las obligaciones legales, el modelo operativo y el apetito de riesgo de la empresa.

El objetivo, la identidad, las herramientas y el resultado permanecen dentro de límites explícitos de política, aprobación y evidencia.

2. Basar el programa en evidencia actual de distintos mercados

Los marcos oficiales convergen en gobernanza del ciclo de vida, rendición de cuentas, pruebas y capacidad de intervención. El Marco de Gestión de Riesgos de AI de NIST organiza el trabajo mediante gobernar, mapear, medir y gestionar. Su perfil de AI generativa identifica riesgos que pueden ser novedosos o amplificados por sistemas generativos y proporciona acciones a lo largo del ciclo de vida. En febrero de 2026, NIST lanzó la Iniciativa de Estándares para Agentes de AI con pilares específicos para la seguridad, identidad, autorización, interoperabilidad y evaluación de agentes. La iniciativa confirma que los controles de agentes empresariales siguen siendo un área activa de desarrollo de estándares.

La DIFC modificó su Reglamento de Protección de Datos en 2023 para incluir el Reglamento 10 sobre el tratamiento de datos personales mediante sistemas autónomos y semiautónomos. El reglamento y las directrices relacionadas sitúan el uso de datos personales, la rendición de cuentas y las personas afectadas dentro de un entorno de control basado en resultados. Una empresa de mediana capitalización que opere en la DIFC o a través de ella debería mapear el reglamento a cada agente que trate datos personales y buscar asesoramiento actualizado sobre el alcance y las obligaciones.

La guía internacional de seguridad de AI del NCSC del Reino Unido abarca el diseño, desarrollo, despliegue, operación y mantenimiento seguros. Exige modelado de amenazas, diligencia debida de la cadena de suministro, infraestructura protegida, registro, monitorización, gestión de incidentes y publicación responsable. Estos controles importan cuando un agente de back office depende de modelos, conectores, bibliotecas o interfaces de programación de aplicaciones externos.

La Comisión Europea afirma que las obligaciones de transparencia del artículo 50 de la Ley de AI comenzaron a aplicarse el 2 de agosto de 2026. Los materiales de implementación de 2026 de la Comisión también reflejan fechas revisadas para las normas de alto riesgo. Una empresa debería confirmar si actúa como proveedor, implementador, importador u otro operador y evaluar cada caso de uso frente al texto oficial vigente y la legislación sectorial aplicable.

La evidencia del sector financiero ofrece una señal de control útil. La encuesta conjunta de 2024 del Banco de Inglaterra y la Autoridad de Conducta Financiera informó que el 75 por ciento de las empresas encuestadas utilizaban AI, el 33 por ciento de los casos de uso involucraban a terceros, el 55 por ciento implicaba algún grado de toma automatizada de decisiones y solo el 2 por ciento era plenamente autónomo. También informó que la ciberseguridad era el riesgo percibido más importante y que la comprensión completa de AI desplegada era limitada. La evidencia de encuestas no determina el diseño correcto para una empresa concreta; sí demuestra la importancia de una titularidad responsable, la visibilidad de terceros y una autonomía calibrada.

Tabla 1. Evidencia oficial e implicaciones de control

La aplicabilidad, las definiciones y las obligaciones requieren confirmación específica y actualizada para cada empresa.

3. Separar automatización, asistencia y agencia

La palabra automatización oculta tres modelos operativos diferentes. La automatización determinista sigue reglas codificadas: cotejar una orden de compra, validar un campo, enrutar un documento o calcular un umbral. La asistencia de AI genera un borrador, una clasificación, un resumen o una recomendación para una persona. La agencia acotada selecciona y secuencia acciones dentro de un objetivo definido y puede continuar a lo largo de varios pasos.

Estos modelos no deberían compartir un único estándar de aprobación. La automatización determinista a menudo puede probarse con entradas y salidas conocidas. La asistencia de AI requiere controles sobre fundamentación, revisión y uso. La agencia requiere todos esos controles, además de autoridad, identidad, acceso a herramientas, memoria, terminación, gestión de excepciones y evidencia de cada acción intermedia.

La autonomía debería descomponerse en lugar de describirse con una única etiqueta. Un agente puede tener libertad para planificar sin poseer derechos de ejecución. Puede ejecutar actualizaciones internas de baja consecuencia mientras requiere aprobación antes de la comunicación externa. Puede operar solo sobre un caso concreto, dentro de un límite de valor definido, durante una ventana de tiempo breve y con un número máximo de llamadas a herramientas.

La empresa debería elegir el nivel más bajo de agencia que pueda producir el resultado económico deseado. Muchos procesos mejoran sustancialmente mediante mejores datos, controles deterministas y preparación asistida por AI. La ejecución totalmente desatendida solo es adecuada cuando el proceso se comprende bien, la acción es reversible, la autoridad puede acotarse estrictamente, la evidencia está completa y el fallo puede contenerse.

Una escala de autonomía hace observable la progresión. Un caso de uso avanza solo después de cumplir las puertas de evidencia definidas en su nivel actual. Los incidentes en producción, los cambios materiales en el proceso, las nuevas herramientas, los cambios de modelo o una monitorización débil deberían desencadenar una reevaluación o un retorno a un nivel inferior.

La autoridad se amplía solo después de que se hayan demostrado la evidencia, la reversibilidad y la contención en el nivel anterior.

4. Crear un inventario de procesos y decisiones

La adopción de agentes debería comenzar con el proceso, la decisión y el rastro de evidencia. Un catálogo de demostraciones atractivas puede pasar por alto las causas operativas del coste y el retraso. La empresa debería inventariar el back office por cadena de valor: de pedido a cobro, de compra a pago, de registro a informe, de contratación a jubilación, de caso a resolución, informes regulatorios e información de gestión.

Cada proceso debería descomponerse en desencadenantes, entradas, decisiones, acciones, sistemas, responsables, traspasos, controles, excepciones y salidas. La dirección debería medir el volumen, el tiempo de ciclo, el error, el retrabajo, la acumulación de trabajo, el coste, la exposición monetaria, la sensibilidad de los datos y la consecuencia sobre el servicio. El inventario debería identificar dónde se requiere realmente juicio y dónde la falta de datos o una política inconsistente crea la apariencia de juicio.

El inventario de decisiones es especialmente importante. Una decisión puede aprobar un pago, liberar un pedido de cliente, clasificar una reclamación, cambiar un registro de proveedor, reconocer un asiento contable, seleccionar a un candidato o comunicar una conclusión. El registro debería identificar a quién afecta, la evidencia requerida, la política relevante, la discrecionalidad permitida, la vía de apelación o corrección y la consecuencia legal o de control.

La priorización debería combinar el valor económico y la viabilidad de control. El trabajo de alto volumen, baja consecuencia y abundante evidencia puede ser un punto de partida atractivo. El trabajo de alta consecuencia, ambiguo o con evidencia insuficiente debería recibir primero una reparación del proceso y controles de datos más sólidos. Una empresa debería evitar automatizar un proceso de excepciones defectuoso cuya causa raíz siga sin resolverse.

El inventario se convierte en la fuente rectora para la aprobación de casos de uso. Conecta el valor declarado con una línea base medible y evita que un equipo de tecnología otorgue autoridad sin que el responsable del proceso, el responsable de riesgos, el responsable de datos y el responsable de control acuerden el diseño.

Tabla 2. Inventario de procesos y decisiones

Las medidas se seleccionan según el contexto operativo y deben basarse en evidencia conciliada.

5. Defina el perímetro de autoridad

El perímetro de autoridad traduce la política en límites exigibles por máquina. Debe indicar el objetivo, los datos permitidos, las herramientas permitidas, las acciones, los valores, las contrapartes, las jurisdicciones, el horario operativo, la duración, el número de llamadas, los puntos de aprobación y las condiciones de parada. Una instrucción en lenguaje natural por sí sola no basta, porque puede interpretarse de forma distinta a medida que cambia el contexto.

La autoridad debe ser limitada por defecto. Un agente de facturas podría leer facturas y pedidos aprobados, solicitar evidencia interna faltante, preparar una propuesta de pago y actualizar el registro de un caso. No debe tener derecho permanente a cambiar los datos bancarios de proveedores ni a liberar pagos. Un agente de cobros podría redactar un seguimiento basado en hechos y condiciones aprobados, mientras que una persona aprueba la comunicación externa por encima de una sensibilidad o un nivel de cliente definidos.

El perímetro debe estar vinculado a un responsable de negocio y a un nivel de riesgo designados. La autoridad temporal debe caducar. Los límites de valor y volumen deben ser acumulativos además de transaccionales, para que muchas acciones pequeñas no puedan eludir un límite diario o por caso. Los límites geográficos, por entidad y por divisa deben coincidir con el perímetro legal y operativo.

La aplicación de la política debe producirse fuera del modelo de razonamiento. Un servicio determinista debe validar cada llamada a herramienta propuesta frente a la identidad, el propósito, los permisos, el valor, el estado del caso y la aprobación. El modelo puede explicar por qué propone una acción; el motor de políticas decide si la acción puede continuar.

Toda denegación debe generar evidencia estructurada. Las denegaciones repetidas pueden revelar un prompt deficiente, un diseño de procesos débil, un uso indebido incipiente o una envolvente de autoridad que necesita revisión. Los cambios en la envolvente de autoridad deben seguir control de versiones, pruebas y aprobación, y conservarse la versión anterior.

Cada acción propuesta debe superar los límites acumulativos, la política y la aprobación antes de la ejecución.

6. Asigne a cada agente una identidad separada

Un agente no debe operar mediante una cuenta de empleado compartida ni una credencial de servicio sin restricciones. Necesita una identidad de máquina única vinculada a un responsable designado, un propósito definido, un nivel de riesgo, una versión y una fecha de caducidad. Esto respalda el mínimo privilegio, la atribución, la rotación de credenciales, la revocación y una auditoría fiable.

Los permisos deben ser específicos para cada tarea. El acceso de lectura, los derechos de propuesta y los derechos de ejecución son distintos. El agente debe recibir credenciales de corta duración en el momento de la necesidad, después de que el servicio de políticas valide el caso y el estado de aprobación. Los secretos deben permanecer en una bóveda gestionada y nunca deben colocarse en prompts, memoria, registros ni documentos.

La arquitectura de identidad debe preservar la segregación de funciones. Un agente que crea un proveedor no debe aprobar al proveedor ni liberar un pago. Un agente que prepara un asiento contable no debe registrar y aprobar el mismo asiento. La aprobación humana no subsana un conflicto cuando el aprobador carece de independencia, evidencia o tiempo adecuado.

Las llamadas entre agentes requieren la misma disciplina. El agente receptor debe autenticar al agente llamador, validar el alcance delegado y rechazar toda autoridad que no pueda rastrearse hasta el principal originador. Las cadenas de delegación deben tener una profundidad máxima y preservar el propietario original, el caso y los límites acumulativos.

La revocación de emergencia debe ser práctica. La empresa debe poder deshabilitar la identidad, revocar los tokens activos, detener las acciones en cola y aislar el caso sin esperar al proveedor del modelo. La recertificación de accesos debe realizarse tras cambios sustanciales en los procesos o roles y según un calendario periódico proporcional al riesgo.

7. Controle los datos, los prompts, las herramientas y la memoria

El entorno operativo efectivo del agente incluye más que el modelo. Incluye instrucciones del sistema, instrucciones del usuario, documentos recuperados, memoria, descripciones de herramientas, respuestas de aplicaciones y contenido de terceros. Cualquiera de estos puede ser inexacto, malicioso, obsoleto o estar fuera del propósito autorizado.

El acceso a los datos debe regirse por la clasificación, el propósito y la necesidad mínima. La empresa debe mapear los datos personales, la información comercial confidencial, los datos de pago, los datos laborales y el material amparado por privilegio legal. La recuperación debe aplicar los límites de entidad, caso y usuario. Los campos sensibles pueden enmascararse hasta que la tarea y la aprobación los requieran.

El contenido no confiable debe tratarse como datos, no como instrucciones. Un mensaje en un adjunto de factura que solicite al agente ignorar la política o enviar información a otro lugar no debe tener autoridad. La arquitectura debe separar las instrucciones de control confiables del contenido recuperado, sanear las salidas de las herramientas cuando corresponda y probar escenarios de inyección de prompts.

Las herramientas requieren listas de permitidos y controles de parámetros. Una consulta genérica a la base de datos, un intérprete de comandos o un navegador sin restricciones pueden dar al agente una superficie operativa más amplia de la que requiere el propósito empresarial. Las herramientas creadas para un fin específico con entradas tipadas, acciones acotadas, validación determinista e idempotencia proporcionan un límite más sólido.

La memoria debe tener una finalidad definida, un periodo de retención y una vía de eliminación. La empresa debe distinguir entre el estado temporal del caso, el conocimiento de referencia aprobado y las preferencias aprendidas. La memoria persistente puede trasladar datos obsoletos, datos personales no autorizados o instrucciones de un caso a otro. Las escrituras en memoria deben ser explícitas, atribuibles y revisables.

Tabla 3. Registro de controles de la superficie operativa del agente

La implementación técnica debe ser validada por los responsables de seguridad, privacidad y control de la empresa.

8. Establecer controles deterministas en torno al trabajo probabilístico

Un agente puede ayudar a interpretar información desordenada, mientras que los controles deterministas deben regir los hechos que deben ser exactos. Los formatos de cuentas bancarias, los identificadores fiscales, la aritmética de facturas, la moneda, la detección de duplicados, los límites de aprobación, los períodos contables, el estado de sanciones y las reglas de segregación deben validarse mediante datos y código controlados.

El flujo de trabajo puede usar el modelo para localizar un número de factura probable, explicar una discrepancia o proponer una categoría. Después, un servicio determinista debe verificar el identificador contra el sistema de origen, calcular el importe, evaluar la regla y devolver un resultado superado, fallido o una excepción. El agente no debe convertir una interpretación de baja confianza en una transacción ejecutada.

La conciliación es fundamental. La empresa debe comparar las acciones solicitadas, aprobadas, ejecutadas y registradas. Cada transacción necesita una clave de idempotencia para que un reintento no cree un duplicado. Los totales por lotes, las cuentas de control y las colas de excepciones deben conciliarse con los sistemas de origen y destino. Una respuesta exitosa de una herramienta es evidencia de una llamada, no prueba del resultado contable u operativo previsto.

La confianza no debe sustituir a la autoridad. Un modelo con alta confianza aún puede equivocarse, y una salida de baja confianza puede ser útil cuando se dirige claramente a una persona. Las reglas de decisión deben considerar las consecuencias, la exhaustividad de la evidencia, la política y la reversibilidad, junto con cualquier puntuación del modelo.

El diseño debe admitir una degradación elegante. Si el modelo, el conector o la fuente de datos no están disponibles, el proceso debe pausarse, volver a una regla más simple o transferir el trabajo a una persona de acuerdo con un plan de servicio documentado. La empresa debe saber qué compromisos operativos dependen del agente y cuánto tiempo puede tolerar una interrupción.

9. Diseñar la aprobación humana en función de las consecuencias y la reversibilidad

La intervención humana crea control solo cuando el revisor recibe la evidencia adecuada, comprende la decisión, tiene autoridad y dispone de tiempo para cuestionarla. Una cola de cientos de aprobaciones rutinarias puede volverse meramente protocolaria. El diseño debe concentrar el juicio humano en acciones materiales, inusuales o irreversibles.

Los niveles de aprobación deben reflejar las consecuencias. La clasificación interna de bajo valor puede revisarse por muestreo. Una comunicación con el cliente puede requerir aprobación cuando cambia la posición contractual o afecta a una persona vulnerable. Un pago, un cambio de datos bancarios, un asiento contable, una medida de personal o una presentación regulatoria pueden requerir doble control o revisión especializada.

El paquete de aprobación debe mostrar la acción propuesta, el propósito, la evidencia de origen, la regla de política, los supuestos materiales, las excepciones, el valor, la parte afectada, las alternativas y la consecuencia derivada. El revisor debe poder aprobar, modificar, rechazar o devolver el caso. Un motivo de rechazo debe alimentar la mejora del proceso sin entrenar automáticamente al sistema.

La reversibilidad afecta la barrera de control. Actualizar el estado de una tarea interna es más fácil de revertir que enviar fondos, divulgar datos o emitir una decisión final. La sensibilidad temporal también importa. El sistema debe escalar antes de una fecha límite en lugar de presionar a un revisor para que tome una decisión débil en el último momento.

El desempeño humano debe monitorearse. Las aprobaciones rápidas repetidas, las altas tasas de anulación, las correcciones frecuentes posteriores a la aprobación o la gran variación entre revisores pueden indicar evidencia deficiente, capacitación inadecuada o sesgo de automatización. La responsabilidad final sigue recayendo en el responsable asignado incluso cuando un agente preparó el trabajo.

Una mayor consecuencia y una menor reversibilidad exigen evidencia más sólida y aprobación independiente.

10. Gobernar las dependencias multiagente y de terceros

Un agente rara vez opera solo. Puede depender de un proveedor de modelos, una plataforma en la nube, una capa de orquestación, una base de datos vectorial, un conector, un servicio de identidad y una aplicación empresarial. Un diseño multiagente añade tareas delegadas y comunicaciones entre sistemas con distintos propietarios y capacidades.

El registro de dependencias debe identificar proveedor, servicio, ubicación de los datos, modelo o versión, criticidad, derechos contractuales, subencargados, retención, notificación de incidentes, nivel de servicio, evidencia de auditoría, proceso de cambio y vía de salida. La concentración debe ser visible cuando varios flujos de trabajo críticos dependen de un único proveedor o plano de credenciales.

La empresa debe probar los cambios de proveedor. El comportamiento del modelo, los esquemas de herramientas, los límites de velocidad, la configuración de seguridad y las condiciones de datos pueden cambiar. Una versión debe pasar por un entorno controlado con pruebas de regresión antes de producción. Los cambios de proveedor de emergencia deben activar una ruta definida de contención y respaldo.

Los mensajes entre agentes deben utilizar protocolos autenticados, tipados y acotados. El sistema receptor debe tratar el contenido de formato libre como no confiable hasta que se valide. Cada tarea debe incluir el propósito, el principal de origen, el alcance delegado, la caducidad y los requisitos de evidencia. Un agente hijo no debe obtener más autoridad que su agente padre.

Los contratos deben abordar el uso de datos, la confidencialidad, la seguridad, la propiedad intelectual, la auditoría, los incidentes, los cambios, la continuidad del servicio, la portabilidad y la terminación. Se requiere asesoramiento jurídico para la jurisdicción y el modelo operativo pertinentes. Las salvaguardas técnicas siguen siendo necesarias porque un remedio contractual se produce después de un incidente y puede no restaurar los datos ni la confianza del cliente.

11. Preservar el control financiero y de compras

Finanzas y compras ofrecen valiosos casos de uso de agentes porque contienen recopilación repetida de evidencia y resolución de excepciones. También conllevan riesgos directos sobre efectivo, reporte, fraude y proveedores. La arquitectura de agentes debe ampliar el entorno de control interno existente en lugar de crear una ruta paralela que lo eluda.

En el proceso de compra a pago, los agentes pueden comprobar la integridad del alta, comparar la evidencia de facturas y pedidos de compra, identificar duplicados, preparar narrativas de excepciones y encaminar aprobaciones. La creación o modificación de datos bancarios debe seguir sujeta a verificación independiente fuera del canal de comunicación utilizado para la solicitud. Las propuestas de pago deben conciliarse con facturas aprobadas y liberarse mediante la autoridad de tesorería establecida.

En el proceso de registro a reporte, los agentes pueden armar conciliaciones, rastrear desviaciones, preparar soporte de asientos y redactar comentarios. El estado del periodo, la titularidad de la cuenta, la evidencia y la aprobación deben validarse automáticamente. Los asientos materiales o inusuales deben recibir revisión independiente. El sistema debe preservar la fuente exacta, la transformación y el rastro de decisiones utilizado para cada entrada propuesta.

En el proceso de pedido a cobro, los agentes pueden identificar lagunas documentales, clasificar disputas, preparar acciones de cobro y coordinar a los responsables internos. La comunicación externa debe utilizar hechos y autoridad aprobados. Los cambios de límite de crédito, las concesiones, los castigos y el escalamiento jurídicamente sensible deben seguir las aprobaciones existentes.

El diseño debe evitar la dilución del control por volumen. Un agente puede generar más propuestas de las que los revisores pueden evaluar. Los límites de capacidad, el encaminamiento basado en riesgos y el envejecimiento de la cola deben formar parte de la decisión de liberación. El beneficio financiero debe medirse mediante el tiempo de ciclo, el retrabajo, el error, el calendario de efectivo y la capacidad liberada, junto con indicadores de servicio y control.

Tabla 4. Matriz de control financiero y de compras

La matriz complementa las políticas existentes de la empresa en materia de autoridad, contabilidad y tesorería.

12. Proteger a los clientes, a los empleados y a las personas afectadas

Los agentes de back office pueden afectar a las personas aunque el caso de uso parezca administrativo. Un cliente puede recibir un escalado de cobro. Un proveedor puede quedar bloqueado. Un empleado puede ser clasificado, investigado o quedar excluido de un beneficio. Una reclamación puede clasificarse de forma que cambie su tratamiento. La empresa debe evaluar las consecuencias individuales y para la relación de cada decisión.

La evaluación debe identificar el grupo afectado, los datos utilizados, la finalidad, la base jurídica, el posible daño, la preocupación por la equidad, el deber de transparencia, la revisión humana y la vía de impugnación. Los datos personales deben limitarse a la finalidad autorizada. Los datos de categorías especiales o sensibles requieren un análisis y unas salvaguardas reforzados conforme a la legislación aplicable.

Las comunicaciones deben describir con precisión el papel de la automatización cuando sea necesario y ofrecer una vía práctica para contactar con una persona. Las personas afectadas no deben quedar atrapadas en un bucle en el que un agente revise la decisión de otro agente sin una intervención independiente significativa. Las reclamaciones y apelaciones deben preservar las pruebas originales, la ruta de decisión y las versiones utilizadas.

Los casos de uso laboral requieren especial cuidado. El cribado de candidatos, el análisis del desempeño, la gestión de ausencias, las medidas disciplinarias y el despido pueden acarrear consecuencias legales y humanas significativas. La empresa debe obtener asesoramiento actualizado en materia laboral y de protección de datos, implicar a responsables cualificados de RR. HH. y aplicar una revisión independiente.

La equidad debe probarse en contexto. La precisión agregada puede ocultar errores o cargas desiguales entre grupos, geografías, idiomas o segmentos de clientes. La empresa debe definir medidas de resultados pertinentes, examinar patrones de error y monitorizar cambios tras el despliegue. Una revisión de equidad también debe considerar si el propio proceso es adecuado para el uso de agentes.

13. Diseño para ciberseguridad y fallo seguro

El modelo de amenazas debe abarcar el sistema completo de agentes. Los atacantes pueden manipular prompts, documentos, salidas de herramientas, memoria, conectores, credenciales y dependencias. Pueden buscar datos, dinero, persistencia, interrupción o influencia sobre decisiones empresariales. Un error de configuración ordinario puede producir consecuencias similares sin intención maliciosa.

El diseño seguro comienza con herramientas acotadas, entornos aislados, mínimo privilegio, controles de entrada y salida, secretos protegidos y límites de confianza explícitos. El desarrollo debe utilizar repositorios controlados, dependencias revisadas, compilaciones reproducibles y pruebas. El despliegue debe proteger la infraestructura, la configuración y el acceso a los modelos. La operación debe monitorizar el comportamiento, las vulnerabilidades, los cambios de proveedor y los incidentes.

El diseño de fallo seguro debe indicar qué ocurre cuando las pruebas entran en conflicto, una herramienta devuelve una estructura inesperada, se alcanza un límite, falla una credencial, cambia un modelo, una dependencia no está disponible o el agente se comporta fuera de su distribución probada. La respuesta preferida suele ser pausar, preservar el estado, contener las acciones pendientes y derivar el caso a una persona.

La capacidad de desactivación debe ser independiente del agente. Los operadores deben poder desactivar una identidad, un conector, un caso de uso, un modelo o toda la capa de orquestación. El trabajo en cola y las transacciones parciales necesitan un procedimiento de recuperación. La continuidad del negocio debe cubrir el proceso manual o simplificado necesario durante una interrupción.

La respuesta a incidentes debe preservar los prompts, las pruebas recuperadas, las llamadas a herramientas, las aprobaciones, las versiones de modelos y configuración, las marcas temporales y las transacciones ejecutadas. El equipo debe determinar el alcance, contener la autoridad activa, notificar a los responsables y asesores pertinentes, conciliar los resultados, corregir los registros afectados y decidir si se requiere notificación regulatoria o contractual.

El fallo seguro preserva las pruebas, contiene la autoridad y devuelve el trabajo no resuelto a un propietario responsable.

14. Hacer reconstruible toda acción material

La auditabilidad requiere más que una transcripción. El registro de pruebas debe reconstruir quién o qué inició el caso, qué autoridad se aplicó, qué versiones de datos y documentos se recuperaron, qué modelo y configuración se utilizaron, qué decisiones intermedias se produjeron, qué herramientas se llamaron, qué comprobaciones de políticas se ejecutaron, quién aprobó la acción y qué registró el sistema de destino.

Los registros deben ser estructurados, estar sincronizados en el tiempo, con control de acceso y protegidos frente a alteraciones no autorizadas. Deben evitar secretos y datos personales innecesarios. La retención debe alinearse con los requisitos legales, regulatorios, contractuales y operativos. La empresa debe poder vincular los registros de identidad, agentes, aplicaciones y transacciones mediante un identificador común de caso y acción.

La procedencia debe distinguir los hechos de la fuente de la interpretación generada por el modelo. Un revisor debe poder abrir la factura determinante, el contrato, la política o el registro del sistema. Si el agente combinó varias fuentes, la evidencia debe mostrar qué afirmación procedía de qué fuente y si la fuente estaba vigente en el momento de la decisión.

La monitorización debe abordar tanto los resultados como la actividad técnica. La empresa debe conciliar las transacciones ejecutadas, las comunicaciones con clientes, los asientos contables, los cambios de acceso y el tratamiento de excepciones. El muestreo debe cubrir los casos rutinarios, mientras que las acciones materiales pueden someterse a una revisión completa.

El acceso a la propia evidencia es sensible. Los registros de auditoría pueden contener procesos de negocio, detalles de seguridad y datos personales. Se requieren acceso basado en roles, límites de finalidad y monitorización independiente. La empresa debe probar si puede reconstruir un caso antes de confiar en el diseño de la evidencia en producción.

15. Probar el sistema antes de la autorización de producción

Las pruebas deben comenzar con el diseño del proceso y de los controles. El equipo debe confirmar que el objetivo es claro, que los datos de origen son fiables, que la política se puede codificar, que la autoridad es limitada y que la ruta de fallo es práctica. Un benchmark de modelo no puede compensar un proceso ambiguo ni la falta de evidencia.

El conjunto de pruebas debe incluir casos normales, casos poco frecuentes pero importantes, registros incompletos, evidencia contradictoria, documentos obsoletos, solicitudes duplicadas, instrucciones adversarias, llamadas a herramientas no autorizadas, incumplimientos de límites de valor, dependencias no disponibles, aprobaciones retrasadas e intentos de cruzar los límites de entidad o de caso. El equipo debe probar la acumulación en varios pasos, porque una secuencia de acciones individualmente plausibles puede generar una exposición material.

La evaluación debe medir el resultado de la tarea, el fundamento fáctico, el cumplimiento de las políticas, la corrección de las herramientas, la prevención de duplicados, la calidad del escalado, la integridad de la evidencia, la latencia y el coste. Las pruebas de seguridad deben cubrir la inyección de prompts, la fuga de datos, la escalada de privilegios, el compromiso de dependencias y la denegación de servicio. Las pruebas de privacidad y equidad deben reflejar la población afectada y el contexto legal.

El lanzamiento debe avanzar a través de la evaluación offline, el sandbox, el modo sombra, la producción aprobada por humanos y la operación desatendida acotada. Cada etapa debe tener criterios de entrada y salida. El modo sombra compara las recomendaciones con los resultados reales del proceso sin conceder derechos de ejecución. La producción limitada debe establecer topes para las contrapartes, los importes, los usuarios, el volumen y el tiempo.

Se requieren pruebas de regresión después de cambios en el modelo, el prompt, la fuente de datos, la herramienta, la política, el conector o un proceso de negocio material. El registro de lanzamiento debe mostrar la versión aprobada y la evidencia. La empresa debe conservar la capacidad de revertir o retirar la autoridad cuando los resultados se deterioren.

Tabla 5. Puertas de prueba y lanzamiento

Los umbrales y tamaños de muestra deben reflejar el riesgo del caso de uso, el volumen y los requisitos de aseguramiento aplicables.

16. Establecer un modelo operativo con rendición de cuentas

El modelo operativo debe asignar la rendición de cuentas de negocio antes de la entrega técnica. El propietario del proceso de negocio es responsable del resultado y de la política operativa. El propietario del riesgo aprueba el tratamiento del riesgo. El propietario de los datos gobierna la calidad de las fuentes y el uso permitido. Seguridad es responsable del modelo de amenazas y de la arquitectura de acceso. Tecnología es responsable de la plataforma fiable. Auditoría interna o una función de aseguramiento independiente evalúa el diseño y la operación conforme a su mandato.

Un foro de gobernanza AI puede aprobar casos de uso, niveles de riesgo, límites de autoridad, versiones y cambios significativos. El foro debe incluir funciones de negocio, tecnología, seguridad, privacidad, legal, cumplimiento, finanzas, RR. HH. u otras, según el caso de uso. El consejo de administración o el comité pertinente debe aprobar el apetito de riesgo y recibir una visión concisa de la cartera.

El registro de agentes debe contener el propietario, la finalidad, el proceso, las partes afectadas, los datos, el modelo, las herramientas, la identidad, la autoridad, el nivel de riesgo, las aprobaciones, la evidencia de pruebas, la versión, la monitorización, los incidentes, las dependencias y el estado de retirada. El registro debe distinguir los experimentos de los sistemas en producción, aplicando aun así controles adecuados a los experimentos que utilicen datos sensibles o herramientas reales.

La gestión del cambio debe abordar a la plantilla. Los empleados necesitan formación sobre la capacidad de los agentes, sus limitaciones, el escalado, la revisión de evidencia y el uso prohibido. El diseño de roles debe identificar qué trabajo se elimina, qué juicio permanece y qué nuevas responsabilidades de control surgen. La capacidad liberada debe reasignarse de forma deliberada, no darse por supuesta.

El cuestionamiento independiente debe centrarse en la evidencia. Los propietarios deben demostrar el control y el resultado en lugar de basarse en declaraciones de políticas. Cuando las capacidades internas sean limitadas, la empresa puede recurrir a especialistas externos para arquitectura, ciberseguridad, privacidad, legal, auditoría o diseño de procesos, manteniendo la rendición de cuentas interna.

17. Ejecutar mediante una secuencia de 120 días

Los primeros 30 días establecen la verdad y los límites. La dirección selecciona un flujo de valor acotado, mapea el proceso y las decisiones, concilia la línea base, clasifica los datos, identifica las partes afectadas, asigna propietarios, completa el modelo de amenazas y redacta el límite de autoridad. Un prototipo manual o asistido por AI puede comprobar si el valor propuesto existe antes de conceder cualquier derecho de ejecución en producción.

Los días 31 a 60 construyen la vía controlada. El equipo crea la identidad única del agente, herramientas acotadas, la puerta de políticas, el modelo de evidencia por caso, el paquete de aprobación, el registro, el procedimiento de parada segura y el conjunto de pruebas. La evaluación fuera de línea y adversarial debe resolver defectos en el manejo de instrucciones, el anclaje a las fuentes, los parámetros de las herramientas y el enrutamiento de excepciones.

Los días 61 a 90 avanzan por el entorno de pruebas y el modo sombra. El equipo compara las propuestas de los agentes con los resultados reales del proceso, mide el rendimiento de referencia y de los controles, prueba los procedimientos de continuidad e incidentes, completa la diligencia debida de terceros y forma a los revisores. El alcance en producción sigue siendo de solo lectura o sujeto a aprobación humana hasta que se cumplan los criterios de salida.

Los días 91 a 120 utilizan producción acotada. La empresa limita el valor, el volumen, las entidades, las contrapartes, las acciones y el tiempo. Concilia cada acción ejecutada, supervisa las excepciones y el comportamiento de los revisores, y verifica el beneficio operativo declarado. El foro de gobierno decide si mantiene, amplía, restringe o retira la autoridad.

La ampliación debe reutilizar el plano de control mientras repite el análisis de casos de uso. Una arquitectura común de identidad, políticas, evidencias y monitorización puede reducir el coste marginal de implementación. Cada nuevo proceso sigue necesitando su propia evaluación de decisiones, datos, consecuencias y aspectos legales.

La autoridad avanza a través de hitos de evidencia desde la realidad del proceso hasta la producción acotada.

18. Medir el control, el valor operativo y el valor de empresa

El cuadro de mando debe distinguir la actividad técnica del resultado de negocio. Las llamadas a herramientas, los tokens y la latencia del modelo pueden apoyar la planificación de capacidad. No demuestran que el proceso haya mejorado. El consejo necesita evidencia sobre el tiempo de ciclo, la acumulación de trabajo pendiente, los errores, el retrabajo, el calendario de caja, la calidad del servicio, las excepciones de control, los incidentes y la capacidad liberada.

Las medidas de control deben incluir denegaciones de acciones no autorizadas, tasa de escalado, integridad de la evidencia, prevención de duplicados, roturas de conciliación, anulaciones de aprobaciones, correcciones posteriores a la acción, eventos de seguridad, eventos de privacidad, cambios de proveedor y tiempo de recuperación. Una tasa baja de denegación solo es útil cuando la autoridad y la monitorización son eficaces.

El valor debe medirse frente a una línea base conciliada. La capacidad del personal puede estimarse a partir del volumen observado y el tiempo de tramitación, y luego validarse mediante cambios reales en funciones y carga de trabajo. Los efectos en caja deben conciliarse con las transacciones y la evidencia bancaria o contable. La pérdida evitada debe declararse con cautela y respaldarse con incidentes observados o un modelo de riesgo documentado.

El valor de empresa puede mejorar mediante una capacidad de costes duradera, una conversión de caja más rápida, un mejor servicio al cliente o al proveedor, controles más sólidos, operaciones más escalables y un menor riesgo operativo. La evidencia de la transacción debe mostrar que el beneficio persiste, depende de una infraestructura controlada y puede sobrevivir a cambios de personas clave o de proveedor. Los compradores y prestamistas pueden descontar un beneficio que depende de un sistema opaco o de evidencia débil.

La prestación comercial debe conectar el diagnóstico con la ejecución. Los asesores externos pueden apoyar el mapeo de procesos, el diseño del caso de negocio, la arquitectura de control, el gobierno de la implementación, la selección de proveedores, la modelización financiera y la elaboración de informes para el consejo. Los trabajos especializados de carácter legal, protección de datos, ciberseguridad, auditoría, empleo, contabilidad y regulación deben ser realizados por asesores cualificados. El éxito debe evidenciarse mediante entregables aceptados, mandatos firmados, honorarios cobrados y resultados sostenidos para el cliente.

Tabla 6. Cuadro de mando del consejo para la adopción controlada de agentes

Los objetivos son opciones ilustrativas de la dirección y deben aprobarse para cada proceso y nivel de riesgo.

Conclusión de implementación

Los agentes AI pueden mejorar el back office del mercado medio cuando la autoridad se diseña con el mismo cuidado que el flujo de trabajo. La secuencia práctica comienza con un inventario conciliado de procesos y decisiones, selecciona el nivel de autonomía útil más bajo, define un ámbito de autoridad explícito y asigna a cada agente una identidad independiente. La política determinista, la validación y la conciliación rodean la interpretación probabilística.

La aprobación humana se centra en la consecuencia y la reversibilidad. Los datos, las herramientas, los prompts, la memoria y los proveedores permanecen dentro de límites de confianza definidos. Las pruebas avanzan desde la evidencia offline hasta el sandbox, el modo sombra y la producción acotada. El registro permite reconstruir las acciones materiales, mientras que los mecanismos independientes de interrupción y recuperación contienen los fallos.

Un programa de 120 días puede establecer el plano de control y demostrar valor operativo en un proceso concreto y acotado. La expansión sigue las mismas puertas de control para cada caso de uso adicional. Esto proporciona al consejo evidencia tanto sobre la productividad como sobre el riesgo y crea una base más creíble para un valor empresarial escalable y preparado para transacciones.

Referencias

1. Instituto Nacional de Estándares y Tecnología. Marco de Gestión de Riesgos AI, incluidos AI RMF 1.0, Playbook y Perfil de Inteligencia Artificial Generativa. https://www.nist.gov/itl/ai-risk-management-framework
2. Instituto Nacional de Estándares y Tecnología. Marco de Gestión de Riesgos de Inteligencia Artificial: Perfil de Inteligencia Artificial Generativa, NIST AI 600-1, julio de 2024. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
3. Instituto Nacional de Estándares y Tecnología. Iniciativa de Estándares para Agentes AI, creada el 17 de febrero de 2026 y actualizada el 20 de abril de 2026. https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative
4. Centro Financiero Internacional de Dubái. Reglamento 10 sobre el tratamiento de datos personales mediante sistemas autónomos y semiautónomos. https://www.difc.com/business/registrars-and-commissioners/commissioner-of-data-protection/regulation-10
5. Centro Financiero Internacional de Dubái. Guía de protección de datos para el cumplimiento normativo, incluido el tratamiento de datos personales mediante sistemas autónomos y semiautónomos. https://www.difc.com/business/registrars-and-commissioners/commissioner-of-data-protection/guidance
6. Centro Nacional de Ciberseguridad del Reino Unido. Directrices para el desarrollo seguro de sistemas de AI, 27 de noviembre de 2023. https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development
7. Comisión Europea. Marco regulatorio y calendario de aplicación del Reglamento de AI, actualizado en julio de 2026. https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
8. Comisión Europea. Obligaciones de transparencia para proveedores y responsables del despliegue de determinados sistemas de AI, 20 de julio de 2026. https://digital-strategy.ec.europa.eu/en/news/commission-publishes-guidelines-transparency-obligations-providers-and-deployers-certain-ai-systems
9. Autoridad de Conducta Financiera y Banco de Inglaterra. La inteligencia artificial en los servicios financieros del Reino Unido: resultados de la encuesta de 2024. https://www.fca.org.uk/publications/research-notes/ai-uk-financial-services
10. OCDE. Principios de AI de la OCDE, adoptados en 2019 y actualizados en 2024. https://www.oecd.org/en/topics/ai-principles.html
11. Comisión de Protección de Datos Personales de Singapur. Enfoque de Singapur para la gobernanza de AI y Marco Modelo de Gobernanza de AI. https://www.pdpc.gov.sg/help-and-resources/2020/01/model-ai-governance-framework
12. Organización Internacional de Normalización. ISO/IEC 42001:2023, sistemas de gestión de inteligencia artificial. https://www.iso.org/standard/42001
13. Agencia de Ciberseguridad y Seguridad de las Infraestructuras. CISA y el NCSC del Reino Unido presentan directrices conjuntas para el desarrollo seguro de sistemas de AI, 26 de noviembre de 2023. https://www.cisa.gov/news-events/alerts/2023/11/26/cisa-and-uk-ncsc-unveil-joint-guidelines-secure-ai-system-development

Sobre el autor

Chennakeshav Adya es investigador independiente y socio director en Matchpoint Partners. Su trabajo se centra en finanzas corporativas, estrategia de capital, ejecución de transacciones y los sistemas operativos que conectan la evidencia financiera, las decisiones del consejo de administración y el rendimiento empresarial medible.