Controles para la IA en la operación: aprobaciones, registros de auditoría y una persona al mando

Treinta y siete reembolsos por 8,400 dólares se aprobaron durante la noche, y todos estaban dentro del límite. El agente de soporte que una cadena de 12 tiendas activó el mes pasado puede reembolsar hasta 300 dólares por vez, y nada en su configuración ponía un tope al día completo.

Después de medianoche llegó una oleada de mensajes que decían que los paquetes llegaron dañados, todos amables y creíbles, y el agente los fue aprobando uno por uno. La responsable de finanzas ve el total el martes por la mañana. Es un escenario ilustrativo, pero cada paso es una falla común de un límite que solo revisa una acción a la vez.

El agente hizo exactamente lo que su prompt le permitía, y el prompt era la única barrera. Un prompt es solo una petición, y las peticiones se pueden ignorar, malinterpretar o anular con un mensaje astuto de un desconocido. La seguridad de verdad viene de controles que están fuera del modelo: permisos, límites, aprobaciones, topes de frecuencia y registros que funcionan igual si el modelo se porta bien o no.

Este artículo es una guía para diseñar esos controles. Cubre quién aprueba qué, cómo hacer que una acción sea segura aunque se repita, qué debe contener un registro de auditoría, cómo defenderte de textos hostiles y qué piden las reglas de la UE, ISO y NIST a un negocio normal a inicios de septiembre de 2026.

Esta es la parte 3 y última de la serie «IA en la operación, 2026». La parte 1 trató sobre lo que los agentes de IA pueden hacer con seguridad dentro de un ERP. La parte 2 explicó cómo MCP conecta la IA con los datos del negocio de forma segura. Esta parte final trata de mantener a una persona al mando.

Por qué los controles deben estar fuera del modelo

Un modelo de lenguaje decide prediciendo el siguiente texto. Casi siempre acierta, a veces se equivoca con total seguridad, y nadie puede prometerte cuál de las dos cosas pasará un día cualquiera. Si lo único que hay entre el modelo y tu sistema de pagos es una frase que dice «nunca reembolses más de 50 dólares», tienes una esperanza, no un control.

Un control es algo que el modelo no puede esquivar con palabras. La herramienta de reembolsos rechaza por sí misma los montos que pasan el límite. La pantalla de aprobación no se la puede saltar el agente. La cuenta del agente no tiene derecho alguno a tocar la nómina. Son reglas aburridas, de código determinista, y por eso funcionan.

Es la misma disciplina que ya aplicas con el personal nuevo: acceso limitado, un tope de gasto y un jefe que firma las decisiones grandes. No te basas solo en su buena voluntad, y con el agente tampoco deberías.

Principio 1: mínimo privilegio, una identidad por agente

Dale a cada agente su propia cuenta, con el nombre de su trabajo, por ejemplo «purchasing-agent». Nunca le prestes el acceso de una persona ni una llave de administrador compartida. Después concédele solo lo que la tarea necesita.

• Alcance de lectura: solo los módulos y campos que necesita. Un agente de compras no necesita los teléfonos de los clientes.
• Alcance de escritura: crear borradores, no contabilizar en el libro mayor. Cambiar etiquetas, no precios.
• Cuándo y desde dónde: que corra solo cuando lo active una persona o un calendario, desde sistemas conocidos.
• Presupuesto: un tope de gasto, de uso del modelo y de acciones por hora.

Una identidad propia rinde frutos después. Cuando algo se vea raro, el registro dirá «purchasing-agent hizo esto en nombre de María», y podrás apagar esa identidad sin molestar a nadie más.

Principio 2: la aprobación depende de la reversibilidad y del monto

La parte 1 ordenó las acciones del agente en cuatro niveles, desde responder hasta mover dinero sin vuelta atrás. En la práctica hace falta un segundo eje: ¿qué tan grande es la acción? Un reembolso de 8 dólares y uno de 8,000 son la misma clase de acción, pero no el mismo riesgo.

Combina los dos ejes en una matriz y déjala por escrito. Los montos de abajo son un ejemplo ilustrativo; define los tuyos según lo que te costaría un error, no según lo que se vea ordenado.

Tres hábitos hacen que la matriz funcione. Decide la casilla según el tipo y el monto de la acción, con código, y no preguntándole al modelo qué tan riesgosa le parece. Envía la acción al aprobador como una propuesta, para que quede claro que todavía no ha pasado nada. Y vuelve a verificar el monto en el momento de aprobar, porque un carrito o un borrador pueden cambiar entre la solicitud y el clic.

Si metes la matriz dentro del recorrido completo de una acción, se convierte en un flujo con cuatro compuertas. Cada salida, incluidos los rechazos, deja un registro.

Principio 3: ejecutor y revisor, vistas previas y simulacros

Los contadores usan desde hace generaciones el principio de ejecutor y revisor (maker-checker): quien prepara un pago no es quien lo libera. Aplica la misma separación a los agentes. El agente siempre es el ejecutor. El revisor es una persona y, en las casillas de mayor riesgo, dos. Un agente nunca debe revisar el trabajo de otro agente cuando hay dinero de por medio.

Un revisor solo puede revisar lo que ve, así que cada propuesta necesita una vista previa clara:

• Qué cambiará exactamente, mostrado como antes y después.
• Por qué lo propone el agente, en dos o tres frases sencillas, con enlaces a los registros que usó.
• Cuánto costará y qué no se podrá deshacer.
• Un resultado de «simulacro» cuando sea posible: la misma acción ejecutada sobre una copia o en simulación, que muestra el resultado sin guardarlo.

Cuidado con la fatiga de aprobaciones. Si le pides a alguien que apruebe doscientos elementos al día, hará clic sin mirar. Reserva las aprobaciones para las casillas que importan, agrupa las de bajo riesgo en una revisión diaria por muestreo y lleva la cuenta de cuántas veces los aprobadores editan o rechazan. Un sello que nunca rechaza no es un éxito, es una alerta.

Haz que cada acción sea segura si se repite

Los agentes reintentan. La red se corta, los trabajos se reinician y a veces el modelo llama dos veces a la misma herramienta. Si «crear orden de compra» se ejecuta dos veces, compras dos veces.

La solución es una llave de idempotencia (idempotency key): una referencia única adjunta a cada acción propuesta. El sistema recuerda qué llaves ya completó e ignora en silencio cualquier repetición. Las facturas duplicadas de proveedores, los reembolsos dobles y las transferencias de inventario repetidas se evitan con este solo hábito.

Súmale otros tres frenos:

• Límites de frecuencia: por ejemplo, no más de 20 ediciones de pedidos por hora por agente. Así un ciclo descontrolado se detiene solo mucho antes de volverse un desastre.
• Cortacircuitos: si suben los errores o los rechazos, el agente se pausa solo y avisa a una persona.
• Un interruptor de emergencia: un control bien rotulado que suspende de inmediato a un agente o a todos. Pruébalo en un día tranquilo. El peor momento para descubrir que no funciona es justo cuando lo necesitas.

El registro de auditoría: qué anotar en cada acción

Cuando algo sale mal necesitas responder rápido cinco preguntas: quién lo pidió, qué vio el agente, qué hizo, qué modelo tomó la decisión y quién aprobó. Si el registro no responde las cinco, no puedes investigar ni demostrarle a un cliente, auditor o regulador qué pasó.

Tres detalles separan un registro útil de uno decorativo. Escribe el registro cuando se propone la acción, no solo cuando termina, para que también se vean las acciones fallidas y rechazadas. Guarda el nombre y la versión del modelo junto con la versión del prompt o de la política, porque el comportamiento cambia si cambia cualquiera de los dos. Y haz que los registros delaten cualquier alteración: almacenamiento de solo agregar o, al menos, una regla que impida a los agentes y a sus administradores editar el historial.

Piensa también en la privacidad. Un registro que guarda los mensajes completos de los clientes es en sí mismo un dato sensible. Anota referencias y extractos cortos cuando puedas, define un plazo de conservación y limita quién puede leerlo.

Cómo defenderte de textos hostiles

La parte 2 explicó la inyección de prompts: texto de un correo, una reseña o la descripción de un producto que le ordena al modelo algo que su dueño nunca pidió. El Top 10 de OWASP para aplicaciones con LLM la pone en primer lugar. Ningún filtro la elimina por completo, así que diseña asumiendo que algunas inyecciones sí funcionarán.

1. Trata todo lo que el agente lee del exterior, como correos, páginas web, reseñas y archivos subidos, como datos no confiables, nunca como instrucciones.
2. Quita las herramientas peligrosas, o pide una confirmación aparte, cuando haya contenido no confiable en la conversación. Un agente que lee el correo de un cliente no debería poder emitir reembolsos en ese mismo paso.
3. Mantén separados los datos sensibles y el canal de salida. Un agente que puede leer a todos los clientes y además enviar correos a cualquiera puede ser engañado para que mande tu lista de clientes afuera.
4. Muestra al aprobador el texto original junto a la propuesta, para que una persona note la instrucción que no pertenece ahí.
5. Registra y revisa los intentos bloqueados. Si su número sube, alguien está tanteando.

Prueba antes de cambiar cualquier cosa

Los modelos, los prompts, las herramientas y tus propios datos cambian, y cualquiera de ellos puede alterar en silencio el comportamiento del agente. Por eso, antes de salir en vivo, arma un pequeño conjunto de evaluación: de cincuenta a unos cientos de casos reales o realistas con la respuesta esperada, incluyendo los incómodos: pedidos duplicados, datos faltantes, clientes enojados e intentos de inyección.

Ejecuta el conjunto cada vez que cambies el modelo, el prompt o los permisos. Compara con la corrida anterior y publica el cambio solo si los números se mantienen o mejoran. Es la misma idea de las pruebas de regresión en software, aplicada al comportamiento.

Después del lanzamiento, vigila cada semana unas pocas cifras: tasa de aceptación de las propuestas, motivos de rechazo, acciones bloqueadas por la política, costo por acción y errores que llegaron a un cliente o proveedor. Y planea la marcha atrás con anticipación. Para cada tipo de acción, sabe cómo se deshace, quién lo hace y de cuánto tiempo dispones. Si la respuesta es «esto no se puede deshacer», esa acción va en la casilla de solo humanos.

Qué piden las reglas, a septiembre de 2026

La mayoría de los usos operativos de la IA en un negocio en crecimiento, como preguntas de inventario, borradores de compra y conciliación de facturas, no se clasifican como «de alto riesgo» según la Ley de IA de la UE. Eso no significa que no haya nada que hacer. Así están las cosas a inicios de septiembre de 2026.

Marco	Situación	Qué significa para ti
Ley de IA de la UE, transparencia (artículo 50)	Aplica desde el 2 de agosto de 2026. Un breve plazo adicional hasta el 2 de diciembre de 2026 cubre solo el marcado del contenido generado por IA en sistemas que ya estaban en el mercado.	Avisa a las personas cuando hablen con una IA y etiqueta el contenido sintético donde corresponda.
Ley de IA de la UE, sistemas de alto riesgo (anexo III)	El Digital Omnibus on AI, acordado en mayo de 2026 y adoptado por el Parlamento y el Consejo en junio de 2026, mueve la fecha del 2 de agosto de 2026 al 2 de diciembre de 2027. Los productos ya cubiertos por la normativa de seguridad de productos de la UE pasan al 2 de agosto de 2028.	Aplica si la IA decide sobre contratación, evaluación de personal, crédito o acceso a servicios esenciales. Exige registros, supervisión humana y documentación.
ISO/IEC 42001:2023	Publicada en diciembre de 2023. Norma de sistema de gestión para IA que se puede certificar.	Opcional. Una estructura útil para políticas, roles, revisión de riesgos y mejora, y una señal de confianza para clientes grandes.
Marco de Gestión de Riesgos de IA del NIST 1.0	Publicado en enero de 2023, con un perfil de IA generativa en julio de 2024. Voluntario.	Cuatro funciones para tomar prestadas: govern, map, measure, manage.

Dos advertencias. Las fechas de una norma como esta ya se movieron una vez, y los detalles del texto final los resúmenes del texto final todavía difieren en su redacción, así que revisa el texto oficial o consulta a un especialista antes de apoyarte en una fecha. Y el aplazamiento es un retraso, no una cancelación: las obligaciones siguen ahí, y los hábitos de este artículo, es decir registros, supervisión y límites documentados, son justo lo que piden las reglas de alto riesgo.

Incluso un uso de bajo riesgo exige dos cosas: avisar a las personas cuando hablan con una IA y conservar los registros. Para ver las normas en sí, consulta la página de ISO sobre la norma ISO/IEC 42001 y el Marco de Gestión de Riesgos de IA del NIST. Fuera de la UE, las reglas cambian de un país a otro y se siguen moviendo, así que revisa dónde vendes.

Una política de acciones de IA que puedes copiar

Pon tus reglas en una sola página que puedan leer el personal, los proveedores y los auditores. Esta es una plantilla con valores ilustrativos. Ajusta cada número a tu propio riesgo.

Acción	El agente puede	Límite	Aprobación	Deshacer
Responder preguntas de inventario y pedidos	Solo leer	Datos de su propio rol	Ninguna	No hace falta
Borrador de orden de compra	Crear borrador	20 borradores al día	El comprador aprueba antes de enviar	Eliminar el borrador
Etiquetar o reservar pedidos	Modificar	Pedidos de menos de 200 dólares, 50 por hora	Revisión diaria por muestreo	Revertir con un clic
Borrador de respuesta a un cliente	Crear borrador	Sin promesas de reembolso ni compensación	El agente no envía nada por sí solo	No se envió
Reembolso	Solo proponer	Hasta 1,000 dólares un aprobador; por encima, dos	Siempre una persona	Revertir en el proveedor de pagos
Pagar a un proveedor, nómina, contabilizar en el libro mayor, eliminar	Nada	No permitido	Solo una persona	No aplica

Revisa la política cada trimestre y después de cada incidente. Cuando la evidencia lo respalde, sube una fila un nivel. Nunca la subas porque lo dice la presentación de un proveedor.

Una lista de verificación para el lanzamiento

1. Crea una identidad separada para cada agente, con los permisos más estrechos que le alcancen para trabajar.
2. Escribe la matriz de aprobación y la política de acciones, y pide que las firmen el dueño y el responsable de finanzas.
3. Aplica los límites y las aprobaciones en el sistema, no en el prompt.
4. Agrega llaves de idempotencia, límites de frecuencia y un interruptor de emergencia ya probado.
5. Registra la solicitud, el agente, la versión del modelo, los datos de entrada, la acción, la decisión, la aprobación, el resultado y la referencia para deshacer.
6. Arma un conjunto de evaluación que incluya intentos de inyección y vuelve a ejecutarlo con cada cambio.
7. Haz un piloto con un equipo, revisa el registro cada semana y amplía el acceso solo con evidencia.

De regreso a ese martes. Con estos controles, cada reembolso habría sido una propuesta esperando a una persona, un tope diario del valor reembolsado habría detenido la corrida tras los primeros casos, y el cortacircuitos habría pausado al agente cuando las propuestas empezaron a parecerse. La responsable de finanzas habría encontrado una alerta de pausa y una cola corta por revisar, no un problema de 8,400 dólares. El agente no es menos capaz que antes. Solo que su peor noche ahora tiene un límite.

Ideas clave

• Los controles van fuera del modelo: permisos, límites y aprobaciones que impone el sistema, no que se piden en un prompt.
• Dale a cada agente su propia identidad acotada y decide la aprobación según la reversibilidad y el monto juntos.
• Usa ejecutor y revisor con vistas previas claras, reserva las aprobaciones para las casillas riesgosas y vigila la fatiga de aprobaciones.
• Haz las acciones idempotentes y suma límites de frecuencia, cortacircuitos y un interruptor de emergencia que hayas probado.
• Registra quién lo pidió, qué vio el agente, qué hizo, qué versión del modelo actuó y quién aprobó.
• La mayoría de los usos operativos no son de alto riesgo según la Ley de IA de la UE, cuya fecha para alto riesgo pasó a diciembre de 2027, pero la transparencia y los buenos registros siguen aplicando.

Anichur Rahaman es arquitecto de software y creador de StoreConsole. Diseña sistemas de comercio y ERP para negocios en crecimiento, con enfoque en arquitectura orientada a eventos, integridad de datos y operación en servidores propios.