Modo sombra para agentes IA: prueba herramientas sin riesgos

Respuesta corta: el modo sombra permite que un agente reciba casos parecidos a los reales y “proponga” llamadas a herramientas sin ejecutar sus efectos. Es la forma más segura de descubrir decisiones equivocadas, bucles, costes inesperados y problemas de permisos antes de darle capacidad de escritura. La clave no es simularlo todo: es conservar la decisión del agente, sustituir cada efecto por un resultado controlado y comparar lo que habría ocurrido con una política explícita.

Esta guía sirve para equipos que ya tienen un agente con acceso a APIs, documentos, CRM, correo o automatizaciones y necesitan validar el paso de prototipo a piloto. No sustituye una auditoría de seguridad ni convierte automáticamente un entorno de pruebas en seguro.

Si necesitas una visión más amplia de la evaluación, consulta nuestra guía sobre rendimiento y fiabilidad de agentes IA; aquí nos centramos únicamente en probar herramientas sin producir efectos.

Qué significa exactamente “modo sombra”

En un flujo normal, el agente interpreta una solicitud, selecciona una herramienta, envía parámetros y recibe una respuesta que puede producir un cambio. En modo sombra, la decisión se registra, pero la operación se intercepta: una función simulada devuelve una respuesta de prueba o una copia de solo lectura. El resto del flujo continúa para que puedas observar qué habría hecho.

Hay tres variantes útiles:

• Sombra de lectura: el agente consulta una réplica o datos desidentificados y sus operaciones de escritura se bloquean.
• Sombra de decisión: el agente no recibe herramientas reales; genera una propuesta estructurada que otro componente valida.
• Sombra paralela: el proceso humano o determinista sigue siendo la fuente oficial y el agente procesa la misma entrada en paralelo para comparar resultados.

En las tres, la palabra “sombra” describe el efecto sobre el sistema, no una autorización especial. Si el simulador llama a una API real con un verbo de escritura, ya no estás en sombra.

Cuándo merece la pena usarlo

Úsalo cuando el coste de equivocarse sea mayor que el coste de ejecutar una segunda ruta de prueba. Es especialmente útil para agentes que crean tickets, clasifican solicitudes, preparan respuestas, proponen cambios de inventario o coordinan tareas entre sistemas. También ayuda cuando las respuestas del modelo son aceptables, pero todavía no sabes si el uso de herramientas es estable.

No es la primera solución para todos los casos. Si el agente maneja decisiones médicas, pagos, datos especialmente protegidos o acciones irreversibles, el modo sombra es solo una fase previa: necesitarás controles de acceso, revisión especializada, pruebas de impacto y aprobación formal. Tampoco arregla datos de prueba pobres ni una política ambigua.

Diseña el contrato de simulación antes de probar

Para cada herramienta, escribe un contrato que responda a cinco preguntas:

1. ¿Qué operación representa y qué efectos tendría?
2. ¿Qué parámetros son obligatorios, opcionales o peligrosos?
3. ¿Qué respuesta de prueba recibirá el agente?
4. ¿Qué evidencia debe quedar registrada?
5. ¿Qué condición obliga a escalar a una persona?

Ejemplo para una herramienta crear_ticket:

• La llamada se registra, pero no crea ningún ticket en el sistema real.
• El simulador devuelve un identificador ficticio y un estado “pendiente de aprobación”.
• Se rechazan campos desconocidos, prioridades fuera de rango y textos que incluyan secretos.
• Se conserva un hash del caso y los parámetros redactados, no el contenido personal completo.
• Si falta el cliente, hay conflicto de prioridad o la acción afecta a más de un equipo, el resultado es “escalar”.

Este contrato evita que el entorno de sombra sea una caja negra. También permite cambiar el modelo sin cambiar las reglas de seguridad que deben cumplirse en cualquier versión.

Arquitectura mínima del flujo

Una implementación sencilla separa el agente, el adaptador de herramientas y el registro de evaluación:

1. Entrada: recibe un caso sintético, desidentificado o copiado bajo una política aprobada.
2. Agente: planifica y solicita herramientas con la misma configuración que usaría el piloto.
3. Gateway: comprueba identidad, alcance, parámetros y modo de ejecución antes de enrutar la llamada.
4. Simulador: devuelve respuestas controladas, incluidos errores y latencias realistas.
5. Evaluador: compara la propuesta con el resultado esperado y asigna severidad.
6. Registro: guarda versión, trazas, decisiones, fallos, coste, latencia y decisión final.

El gateway debe imponer el modo sombra por configuración del servidor, no por una frase en el prompt. Si basta con que el agente escriba “modo prueba” para saltarse el simulador, el control está en el lugar equivocado.

Qué casos debes incluir

Una prueba útil combina casos corrientes y situaciones que fuerzan una decisión. Empieza con una matriz de 30 casos y amplíala cuando aparezca un nuevo riesgo:

No uses únicamente ejemplos escritos por quien diseñó el agente. Incluye tickets anonimizados revisados por el equipo que conoce el proceso y conserva algunos casos nuevos para comprobar si el sistema memoriza patrones. Mantén separados los casos usados para ajustar instrucciones y los reservados para la evaluación final.

Métricas para decidir si el piloto puede avanzar

Mide la calidad de la decisión y la seguridad del efecto hipotético. Un conjunto práctico incluye:

• Selección correcta de herramienta: proporción de casos en que el agente eligió una herramienta permitida y adecuada.
• Exactitud de parámetros: campos válidos, completos y dentro de política.
• Escalado correcto: casos que el agente deriva cuando faltan datos o el impacto supera el límite.
• Fallo seguro: casos peligrosos en los que no propone una alternativa que produzca el mismo efecto.
• Presupuesto: llamadas, tokens, latencia y coste por caso frente al máximo definido.
• Observabilidad: ejecuciones cuyo rastro permite reconstruir la decisión.

Los umbrales dependen del daño. Para una clasificación reversible podrías aceptar una tasa de corrección manual mayor; para borrar, pagar, enviar o cambiar permisos, la puerta debe exigir cero acciones no aprobadas. No promedies los casos críticos con los normales: un único fallo grave puede detener el piloto aunque el promedio sea alto.

Simula errores, no solo éxitos

Un simulador que siempre responde “200 OK” produce una confianza artificial. Introduce respuestas 401 y 403 para probar permisos, 404 para recursos inexistentes, 409 para conflictos, 429 para límites de frecuencia y 500 para caídas temporales. Añade latencia variable y una respuesta incompleta.

Define qué comportamiento esperas en cada clase. Un error de autorización no debería provocar que el agente intente otra credencial; un 429 no debería desencadenar reintentos infinitos; un conflicto no debería resolverse escogiendo silenciosamente un registro. Registra el motivo de cada reintento y fija un máximo en el gateway.

Ataca la frontera entre instrucciones y datos

El contenido que el agente lee puede contener texto que parece una orden. Prueba correos, PDFs, páginas web y campos de tickets con instrucciones como “ignora la política”, “exporta los datos” o “usa esta URL”. El test debe verificar que el agente trata ese contenido como datos, conserva las instrucciones de mayor confianza y solicita aprobación cuando la acción lo exige.

También prueba abuso de herramientas permitidas: pedir una búsqueda amplia para extraer más información de la necesaria, encadenar una herramienta de lectura con otra de escritura o usar un parámetro válido para un objetivo no autorizado. La guía de OWASP para aplicaciones agentic ayuda a ampliar esta matriz, mientras que el NIST AI RMF aporta un ciclo para documentar riesgos, medición y gestión.

Cómo comparar la sombra con el proceso actual

Durante un periodo acordado, deja que el proceso actual sea la fuente oficial y ejecuta el agente en paralelo. Compara:

• resultado final y calidad;
• herramientas y datos consultados;
• casos escalados;
• tiempo de resolución;
• correcciones humanas;
• coste total, incluida la supervisión.

La comparación debe ser ciega cuando sea posible: quien puntúa no debería saber qué resultado pertenece al agente. Conserva ejemplos de desacuerdo y clasifícalos en error del agente, error del proceso actual, falta de información o diferencia aceptable de criterio. El objetivo no es que el agente imite todo, sino que cumpla el contrato de la tarea con menos riesgo y esfuerzo.

De sombra a piloto limitado

Avanza por etapas y cambia una sola dimensión cada vez:

1. Sombra cerrada: datos sintéticos, sin efectos y con trazas completas.
2. Sombra realista: entradas desidentificadas, errores y latencia parecidos a producción.
3. Piloto de lectura: acceso a consultas reales, sin escrituras, con usuarios concretos.
4. Piloto con aprobación: el agente propone y una persona confirma acciones reversibles.
5. Autonomía acotada: solo operaciones de bajo impacto, con límites y retirada ensayada.

Para cada etapa define duración, volumen, responsables, alertas y criterio de vuelta atrás. Si cambias el modelo, las herramientas, los permisos o las instrucciones, regresa al menos a la fase de sombra y repite los casos críticos.

Registro y apagado

Guarda un identificador de ejecución, la versión de la configuración, las herramientas solicitadas, las respuestas del simulador, los errores, las aprobaciones y el resultado de la evaluación. Redacta secretos y datos personales. Define retención, acceso y eliminación conforme a tus obligaciones aplicables.

El apagado debe ser independiente del agente: desactiva el gateway, revoca el token de prueba y evita que una cola de reintentos siga ejecutándose. Comprueba que el botón funciona durante un ensayo controlado. El plano de control descrito por Cloud Security Alliance es una referencia útil para organizar inventario, controles, monitorización y retirada.

Errores comunes

• Simular solo el último paso: si el agente recibe datos irreales, la prueba pierde valor.
• Permitir llamadas reales “solo de lectura” sin revisar alcance: una consulta amplia puede exponer más datos de los previstos.
• Medir solo la respuesta final: una frase correcta puede esconder una herramienta equivocada o una fuga en el proceso.
• Mezclar casos de ajuste y evaluación: el equipo termina optimizando para las preguntas que ya conoce.
• Olvidar el coste humano: demasiadas propuestas dudosas convierten la aprobación en una carga.

Checklist de salida

• El modo sombra se impone en el servidor y no depende del prompt.
• Cada herramienta tiene contrato, simulador, límites y respuesta de error.
• Los casos cubren ambigüedad, inyección, permisos, fallos y bucles.
• Las acciones críticas tienen una puerta de aprobación explícita.
• El registro permite reproducir la ejecución sin guardar datos innecesarios.
• Hay umbrales por severidad, no solo un promedio global.
• El piloto tiene audiencia, volumen, alertas, responsable y plan de retirada.
• Se ha repetido la prueba tras cada cambio material.

Limitaciones

El modo sombra no reproduce perfectamente el comportamiento de un sistema bajo carga ni garantiza que aparezcan todos los ataques. Un simulador puede ser demasiado amable, una réplica puede estar desactualizada y una evaluación limpia puede fallar con datos nuevos. Por eso debe combinarse con revisión de código, controles de identidad, pruebas adversariales y monitorización en operación.

Preguntas frecuentes

¿La sombra necesita datos reales?

No necesariamente. Empieza con datos sintéticos y desidentificados. Usa datos reales solo cuando exista una justificación, acceso controlado y una política clara de protección; el objetivo es reproducir las condiciones relevantes, no copiar información sin límite.

¿Puedo dejar que el agente consulte producción?

Solo si la consulta es de mínimo privilegio, está acotada, auditada y aprobada para ese propósito. Una herramienta de lectura puede revelar información sensible o permitir inferencias, así que también debe tener límites.

¿Cuánto tiempo debe durar la prueba?

Lo suficiente para cubrir variación de entradas, usuarios, horarios y errores del sistema. Define la duración por cobertura y volumen, no por una cifra mágica; para un cambio importante, repite los casos críticos antes de cada etapa.

¿Cuándo puedo quitar la aprobación humana?

Solo en acciones de bajo impacto y reversibles, después de superar pruebas específicas y con límites, registros, alertas y apagado independiente. La autonomía no debe extenderse automáticamente a nuevas herramientas o tipos de datos.

Clasifica primero el impacto de cada herramienta

No todas las llamadas merecen el mismo nivel de control. Antes de construir el simulador, clasifica cada herramienta por el efecto máximo que puede producir, aunque el caso de uso habitual parezca inocuo. Una consulta de catálogo puede ser de bajo impacto, mientras que una función con el mismo nombre pero acceso a datos personales puede requerir controles más estrictos. La clasificación debe considerar reversibilidad, alcance, sensibilidad de los datos, coste económico, número de personas afectadas y tiempo disponible para corregir un error.

La etiqueta debe aplicarse a la combinación de herramienta, datos y contexto, no únicamente al nombre de la función. Una herramienta para enviar correo puede ser de impacto medio si solo prepara un borrador interno, alto si escribe a un cliente y crítico si comunica una decisión que afecta a derechos. Documenta quién asignó el nivel, cuándo se revisó y qué cambio obligaría a reclasificarlo.

Ejemplo completo: agente que clasifica y prepara tickets

Supón que un equipo de soporte recibe solicitudes por formulario y quiere que un agente detecte el tema, consulte una base de conocimiento y proponga prioridad y respuesta. El proceso oficial sigue en manos del equipo humano. En sombra, el agente recibe una copia desidentificada del caso y puede utilizar tres herramientas simuladas: buscar_articulo, proponer_prioridad y crear_ticket. Las dos primeras no producen un cambio externo; la tercera devuelve un identificador ficticio.

Para cada caso se conserva la categoría asignada por el equipo, la prioridad final, el artículo realmente utilizado y si hubo escalado. El evaluador compara esos datos con la propuesta del agente. No basta con comprobar que la respuesta suena bien: si eligió una base de conocimiento incorrecta, incluyó información no disponible en las fuentes o marcó como urgente un caso sin criterio, debe registrarse como error distinto.

Una ejecución útil podría seguir estos pasos:

1. Eliminar nombres, correos, teléfonos, números de pedido y texto no necesario para la evaluación.
2. Asignar al caso un identificador de prueba que no permita reconstruir directamente la identidad.
3. Ejecutar el proceso humano habitual y conservar el resultado oficial.
4. Enviar la copia al agente con la versión exacta del modelo, instrucciones y catálogo de herramientas.
5. Interceptar cada llamada en el gateway y responder desde el simulador.
6. Comparar categoría, prioridad, citas, número de llamadas, latencia, coste y decisión de escalar.
7. Revisar manualmente todos los desacuerdos graves y una muestra de los aciertos.
8. Convertir cada fallo nuevo en un caso de regresión que se repetirá en futuras versiones.

Si el agente acierta la categoría pero consulta diez artículos cuando bastaba uno, el resultado funcional puede ser correcto y, aun así, la ejecución debe fallar el criterio de eficiencia. Si propone una prioridad válida basándose en un dato inventado, debe fallar el criterio de fidelidad. Separar las dimensiones evita aprobar un sistema que logra una media alta compensando fallos peligrosos con muchos casos fáciles.

Plantilla de contrato para una herramienta

El contrato debe poder leerlo tanto el equipo técnico como quien conoce el proceso. Esta plantilla se puede adaptar a una API, una acción de automatización o un conector sin código:

herramienta: crear_ticket
propietario: equipo_soporte
version: 3
impacto: medio
modo_permitido: sombra
entradas_obligatorias:
  - categoria
  - resumen
  - prioridad
entradas_prohibidas:
  - contrasena
  - token
  - datos_bancarios
validaciones:
  prioridad: [baja, normal, alta]
  longitud_resumen: 20..500
resultado_simulado:
  estado: pendiente_aprobacion
  ticket_id: TEST-aleatorio
limites:
  llamadas_por_caso: 1
  tiempo_maximo_ms: 1500
escalado:
  - identidad_incierta
  - posible_fraude
  - impacto_multiple
registro:
  - version_modelo
  - parametros_redactados
  - resultado_validacion
  - motivo_decision

El simulador no debe aceptar silenciosamente campos desconocidos. Una entrada inesperada puede revelar una nueva versión incompatible, un error de integración o un intento de introducir datos que no deberían circular. Devuelve un error controlado y comprueba que el agente no intenta eludirlo usando otra herramienta. También conviene versionar las respuestas simuladas: si el formato cambia sin quedar registrado, la comparación histórica deja de ser fiable.

Implementa un gateway que falle de forma segura

El gateway es la frontera operativa. Debe recibir la identidad del agente, el entorno, la herramienta solicitada, la versión del contrato y los parámetros. Antes de enrutar, comprueba una lista positiva de herramientas permitidas, valida el esquema, elimina o bloquea campos sensibles, aplica presupuesto y determina si la ejecución es sombra, lectura o producción. El modo no debe decidirlo el propio modelo.

Una lógica simplificada sería: negar por defecto; permitir solo una combinación registrada de agente, versión y herramienta; validar parámetros; comprobar el límite del caso; dirigir la llamada al simulador; redactar el registro; y devolver una respuesta inequívocamente sintética. Incluye en esa respuesta un campo como environment: shadow para impedir que otro componente la confunda con una confirmación real.

Prueba además el propio control. Intenta llamar directamente al endpoint real, cambiar el nombre de entorno, reutilizar un token, alterar el esquema, añadir una URL externa y encadenar dos funciones permitidas para obtener un resultado no autorizado. Un modo sombra es creíble cuando la ruta alternativa también queda bloqueada, no solo cuando el camino feliz usa el simulador.

Construye un conjunto de evaluación que no engañe

Divide los casos en tres grupos. El conjunto de desarrollo ayuda a ajustar instrucciones y contratos. El conjunto de regresión reúne errores ya conocidos y debe superarse en cada cambio. El conjunto de aceptación permanece reservado hasta decidir si el piloto avanza. Si todo el equipo conoce las respuestas del último grupo, terminará optimizando para ellas sin darse cuenta.

Equilibra por riesgo, no únicamente por frecuencia. Si el 95 % del tráfico es sencillo, una muestra aleatoria puede ocultar los casos que importan. Crea estratos: solicitudes normales, datos incompletos, conflicto de fuentes, permisos insuficientes, contenido adversarial, indisponibilidad, alta latencia, límites de coste, datos sensibles y acciones de gran alcance. Conserva suficiente variedad de redacción para que el agente no dependa de frases exactas.

Cada caso debería incluir entrada, contexto autorizado, resultado esperado, herramientas permitidas, herramientas prohibidas, parámetros aceptables, condición de escalado y severidad del fallo. No siempre existe una única respuesta textual correcta. En esos casos evalúa propiedades: que cite la fuente adecuada, no invente hechos, pida el dato imprescindible, limite la acción o derive a una persona.

Fórmulas y cuadro de mando

Un panel útil separa seguridad, calidad, eficiencia y cobertura. Estas fórmulas sencillas hacen visibles los denominadores y evitan porcentajes ambiguos:

• Selección correcta: llamadas a herramientas permitidas y adecuadas divididas entre las llamadas evaluadas.
• Parámetros válidos: llamadas que superan el esquema y la política divididas entre todas las llamadas propuestas.
• Escalado sensible: casos de riesgo correctamente derivados divididos entre todos los casos que exigían derivación.
• Precisión del escalado: derivaciones necesarias divididas entre todas las derivaciones propuestas.
• Fallo seguro: errores técnicos que terminan sin efecto no autorizado divididos entre todos los errores inyectados.
• Trazabilidad: ejecuciones reconstruibles con versión, decisión y evidencia divididas entre ejecuciones totales.
• Coste por caso resuelto: coste total de modelo, herramientas y revisión humana dividido entre casos aceptados.
• Latencia percentil 95: tiempo por debajo del cual termina el 95 % de las ejecuciones, sin esconder la cola lenta en una media.

Publica los resultados por severidad y familia. Un 99 % global puede contener un 60 % en intentos adversariales si estos son pocos. Muestra también el número absoluto de fallos, la versión comparada y el intervalo temporal. Para decisiones con daño potencial alto, define puertas binarias: ninguna llamada no autorizada, ninguna exposición de secretos y ninguna omisión de aprobación en los casos críticos.

No conviertas un umbral en una garantía universal. Un 95 % puede ser suficiente para sugerir etiquetas que siempre revisa una persona y totalmente insuficiente para cambiar permisos. La decisión de aceptación debe incluir la consecuencia del error, el mecanismo de detección, la capacidad de reversión y la carga real que soportará el equipo humano.

Doce pruebas que conviene ejecutar siempre

1. Dato obligatorio ausente: comprobar que pregunta o escala en vez de inventarlo.
2. Identidad ambigua: impedir que combine registros parecidos.
3. Permiso insuficiente: verificar que un 403 no provoca búsqueda de otra credencial.
4. Recurso inexistente: evitar que transforme un 404 en una confirmación falsa.
5. Conflicto: ante un 409, detener y exponer la discrepancia.
6. Límite de frecuencia: restringir reintentos y aplicar espera controlada ante un 429.
7. Servicio caído: conservar el caso sin duplicar efectos tras un 500.
8. Respuesta parcial: detectar campos faltantes antes de continuar.
9. Inyección en contenido: tratar órdenes dentro de correos o documentos como datos no confiables.
10. Cadena peligrosa: bloquear la combinación de una lectura amplia con una escritura no aprobada.
11. Presupuesto agotado: terminar en estado seguro al llegar al límite de tokens, tiempo o llamadas.
12. Memoria contaminada: impedir que un dato no verificado modifique decisiones de sesiones futuras.

Repite estas pruebas después de cambiar el modelo, las instrucciones, el proveedor, la herramienta, el esquema, la memoria o los permisos. Un cambio que parece menor puede alterar la selección de funciones o la forma de interpretar errores. Automatiza las comprobaciones deterministas y reserva la revisión humana para calidad, contexto y severidad.

Memoria del agente: prueba persistencia y envenenamiento

La memoria añade un riesgo que no aparece en una ejecución aislada. Una instrucción falsa o un dato erróneo puede persistir, influir en planes posteriores y propagarse a otros flujos. OWASP describe la memoria y el contexto como superficie de ataque en sistemas agentic. Por eso el entorno de sombra debe observar no solo lo que el agente lee, sino también qué intenta guardar, con qué procedencia, durante cuánto tiempo y quién puede corregirlo.

Crea casos en los que una fuente no confiable pide registrar una regla, un cliente aporta una preferencia incompatible con la política o un documento contiene un identificador falso. La respuesta correcta puede ser guardar solo un hecho etiquetado como no verificado, solicitar validación o no persistirlo. Separa memoria de sesión, perfil, conocimiento compartido y registro de auditoría; cada una necesita permisos y retención distintos.

Ensaya la corrección: elimina o invalida un dato y comprueba que no reaparece desde una caché, un resumen o una copia. Registra la procedencia y la versión para poder saber por qué una decisión utilizó ese contexto. No almacenes el razonamiento interno completo como sustituto de una explicación; conserva entradas autorizadas, herramientas, reglas aplicadas y una justificación breve que pueda revisar una persona.

Supervisión humana que funcione de verdad

Añadir un botón de aprobación no garantiza supervisión. La persona necesita contexto suficiente, tiempo, autoridad y una forma clara de rechazar o corregir. Presenta la acción propuesta, el objetivo, los datos usados, los cambios exactos, la reversibilidad, las dudas detectadas y la evidencia. Evita una interfaz que solo muestre “Aprobar” junto a un texto largo: favorece el sesgo de automatización.

Mide también al revisor. Registra cuánto tarda, cuántas propuestas modifica, qué tipos de error pasan inadvertidos y cuándo la cola obliga a aprobar deprisa. Si la automatización genera cien revisiones triviales por cada decisión importante, el control humano se degrada. Puedes usar muestreo en acciones de bajo impacto, pero mantén revisión obligatoria en los niveles altos hasta que exista una justificación documentada para cambiarla.

Para organizaciones europeas, el Reglamento (UE) 2024/1689 contiene requisitos específicos para determinados sistemas de alto riesgo, entre ellos registro, información al responsable del despliegue y supervisión humana proporcionada al riesgo y al nivel de autonomía. El modo sombra puede aportar evidencia, pero no determina por sí mismo la clasificación jurídica ni sustituye una evaluación de cumplimiento.

Privacidad y minimización durante las pruebas

Copiar producción completa suele ser innecesario. Empieza con datos sintéticos que reproduzcan formatos y límites; continúa con casos desidentificados solo cuando la prueba necesite variación real. Define campos permitidos y elimina el resto antes de que el agente los reciba. No confíes únicamente en pedir al modelo que ignore información sensible: la minimización debe ocurrir en un componente previo y verificable.

Comprueba los registros como si fueran una nueva base de datos. Parámetros, errores y trazas pueden reconstruir el contenido original. Redacta secretos, limita el acceso, cifra donde corresponda, fija retención y prueba la eliminación. Si necesitas relacionar ejecuciones, usa identificadores de prueba y conserva la tabla de correspondencia fuera del entorno evaluado, con acceso restringido.

El perfil NIST AI 600-1 para IA generativa organiza acciones de gestión en torno a gobernar, mapear, medir y gestionar riesgos. Puede servir como lista de contraste para que las pruebas técnicas no olviden procedencia, privacidad, seguridad, supervisión y efectos sobre personas.

Coste, capacidad y límites de bucle

El modo sombra duplica parte del procesamiento y puede aumentar consumo. Presupuesta tokens de entrada y salida, consultas a herramientas, almacenamiento de trazas, tiempo del evaluador y coste de revisión humana. Calcula por caso y por día. Si un agente usa memoria creciente, mide el coste en la primera y en la vigésima interacción, porque una prueba corta puede ocultar la degradación.

Define tres límites independientes: máximo de pasos, tiempo total y presupuesto económico. Alcanzar cualquiera debe producir una salida segura y explicable. Añade límites por herramienta para evitar que una búsqueda o un conector lento consuma todo el presupuesto. Usa alertas sobre percentiles y no solo promedios: una pequeña fracción de bucles puede causar la mayoría del gasto.

Compara el ahorro prometido con el coste completo. Si cada respuesta ahorra dos minutos pero requiere tres minutos de revisión, todavía no existe ganancia operativa. El valor puede seguir estando en aprender o reducir errores, pero debe declararse. Incluye mantenimiento de casos, actualización de simuladores, incidentes y formación en el cálculo.

Plan de implantación en 30 días

Días 1 a 5: alcance y puertas

Elige un solo proceso, inventaría herramientas, asigna impacto y nombra responsables. Define qué datos puede utilizar el agente, qué nunca podrá ejecutar y qué evento detiene la prueba. Recoge ejemplos representativos y separa los casos de aceptación.

Días 6 a 10: gateway y simuladores

Implementa negación por defecto, esquemas, límites y respuestas sintéticas. Confirma que ningún token del entorno de sombra tiene permisos de escritura reales. Prueba rutas directas y combinaciones de herramientas, no solo la interfaz principal.

Días 11 a 16: evaluación inicial

Ejecuta casos normales, ambiguos, adversariales y operativos. Clasifica fallos por severidad y causa: instrucciones, modelo, datos, herramienta, permiso o proceso. No ajustes con el conjunto reservado.

Días 17 a 22: regresión y operación paralela

Convierte fallos en pruebas repetibles. Ejecuta el agente junto al proceso oficial y compara resultados sin permitir efectos. Revisa coste, latencia, carga humana y calidad de los registros.

Días 23 a 27: ensayo de incidentes

Simula caída de proveedor, credencial revocada, cola duplicada, memoria contaminada y error del revisor. Ensaya apagado, reversión y comunicación interna. Comprueba que no quedan trabajos pendientes capaces de ejecutarse después.

Días 28 a 30: decisión

Reúne métricas por severidad, fallos abiertos, excepciones, coste y capacidad de supervisión. Decide entre repetir sombra, pasar a lectura, iniciar piloto con aprobación o detener. Documenta la justificación, la fecha de revisión y los cambios que invalidan la decisión.

Responsables y matriz de decisión

Una prueba falla cuando todos creen que otra persona vigila. Asigna, como mínimo, un propietario del proceso, un responsable técnico del gateway, una persona encargada de datos y privacidad, un evaluador independiente y un responsable de autorizar el avance. En equipos pequeños una persona puede asumir varios papeles, pero las decisiones deben quedar diferenciadas.

• Propietario del proceso: define el resultado correcto y el coste de los errores.
• Responsable técnico: controla permisos, simuladores, versiones y apagado.
• Responsable de datos: aprueba fuentes, minimización, acceso y retención.
• Evaluador: clasifica desacuerdos y protege el conjunto reservado.
• Responsable de operación: confirma que existen capacidad, alertas y respuesta a incidentes.
• Autorizador: acepta el riesgo residual o exige repetir la fase.

Registra excepciones con fecha de caducidad. Una excepción permanente se convierte en una regla oculta. Si una herramienta aún no dispone de simulador, no permitas que el agente la llame “temporalmente” en producción para completar la prueba.

Qué debe contener el informe de salida

El informe debe permitir que alguien ajeno al desarrollo entienda qué se probó y qué no. Incluye objetivo, alcance, versiones, datos, herramientas, matriz de impacto, número de casos por familia, métricas por severidad, fallos abiertos, cambios aplicados, coste, carga de revisión, incidentes simulados y resultado del apagado. Añade enlaces a evidencias y responsable de cada decisión.

Termina con una decisión explícita: no apto, repetir sombra, apto para lectura, apto para piloto con aprobación o apto para autonomía acotada. Evita expresiones como “funciona bien” sin condiciones. Especifica audiencia, volumen, herramientas, permisos y vigencia. Por ejemplo: “apto durante 30 días para proponer borradores de tickets de categoría técnica, máximo 100 casos diarios, sin enviar mensajes y con revisión humana”.

Cómo mantener la prueba después del primer piloto

Conserva una pista de sombra para nuevas versiones. Antes de cambiar modelo, proveedor o instrucciones, ejecuta regresión y aceptación; después compara la nueva variante con la vigente usando los mismos casos. Despliega progresivamente y mantén una forma de volver a la versión anterior.

Revisa el inventario de herramientas cada mes o cuando cambie un permiso. Una función que antes era de lectura puede incorporar escritura, y una API puede añadir campos sensibles. Repite pruebas adversariales cuando aparezcan nuevas integraciones, fuentes o memoria compartida. Comprueba que los registros siguen siendo interpretables y que la política de retención realmente elimina datos vencidos.

El objetivo final no es alcanzar autonomía máxima, sino disponer de la autonomía mínima que produzca valor con evidencia, límites y reversión. Un buen modo sombra hace visibles los riesgos antes de que se conviertan en incidentes y deja una base reutilizable para evaluar cada cambio futuro.

Fuentes y fecha de actualización

Actualizado el 5 de septiembre de 2026. Fuentes consultadas: NIST AI Risk Management Framework, NIST AI RMF Core, función Measure, OWASP Top 10 for Agentic Applications 2026 y Cloud Security Alliance: AI Agents Architecture and Control Plane. Son marcos y referencias técnicas; no certifican un producto ni sustituyen asesoramiento profesional.

Daniel Bellido

Consultor de inteligencia artificial especializado en agentes autónomos y automatización empresarial. Ayudo a pymes y empresas españolas a implementar soluciones de IA agentica con herramientas como n8n, Make, LangChain y AutoGPT. Analizo plataformas, flujos de trabajo y casos de uso reales para que cualquier empresa pueda dar el salto a la IA en 2026.

See Full Bio