Auditoría de agentes IA: 32 pruebas antes de producción

Un agente de IA no está listo para producción porque complete una demo. Está listo cuando la empresa puede demostrar qué objetivo cumple, qué datos consulta, qué acciones puede ejecutar, cómo se mide su calidad, quién aprueba lo delicado y cómo se detiene o revierte si algo falla. Esta guía convierte esas preguntas en 32 pruebas verificables.

La diferencia entre un prototipo vistoso y un sistema que puede trabajar dentro de una empresa aparece en los días malos. El correo llega incompleto. El CRM devuelve un dato antiguo. Una herramienta se queda sin conexión. El modelo interpreta mal una instrucción. Un documento contiene texto diseñado para manipular al agente. El coste por tarea se multiplica. El responsable que debía aprobar una acción no está disponible. Si el proyecto solo se ha probado con el caso feliz, todavía no se ha probado.

Por eso esta auditoría no empieza preguntando qué modelo utiliza el agente. Empieza preguntando qué puede romper, qué evidencia existe y quién asume la decisión. El modelo importa, pero es una pieza dentro de un sistema formado por datos, herramientas, permisos, reglas, personas, registros y proveedores. Una respuesta brillante no compensa un permiso excesivo. Una automatización rápida no compensa una decisión imposible de explicar. Una buena tasa media no compensa un único fallo capaz de enviar datos de un cliente a otro.

La propuesta es una matriz YAG 4 x 8: ocho bloques con cuatro pruebas cada uno. No es una certificación ni una norma oficial. Es un marco operativo para que dirección, operaciones, tecnología, protección de datos y proveedor hablen de la misma cosa con evidencias concretas. Se apoya en el enfoque de gestión de riesgos del NIST AI Risk Management Framework, en las amenazas descritas por OWASP para sistemas agénticos y en las orientaciones de la AEPD sobre IA agéntica.

Si todavía estás definiendo el caso de uso, empieza por nuestra guía sobre agentes de IA para empresas. Si el flujo ya existe y necesitas comprobar si merece acceso al CRM, al correo, a la telefonía o a una API, sigue leyendo.

Resumen: el veredicto en cinco minutos

Antes de entrar en las 32 pruebas, hay seis preguntas que permiten detectar si un proyecto está preparado para una auditoría real o sigue siendo una idea:

1. ¿Existe una tarea concreta, una línea base y un responsable de negocio?
2. ¿Hay un inventario de los datos y sistemas que el agente puede consultar o modificar?
3. ¿Cada permiso está limitado a lo imprescindible y separado por entorno?
4. ¿Se ha probado con casos normales, ambiguos, adversarios y fallos de herramientas?
5. ¿Toda acción sensible requiere aprobación, deja registro y puede detenerse?
6. ¿Hay una persona responsable del sistema después de la puesta en marcha?

Si alguna respuesta es "no lo sabemos", el agente no debe recibir más autonomía. Puede seguir en investigación o en simulación, pero todavía no en producción. La incertidumbre no es un defecto moral ni una razón para cancelar la iniciativa. Es un dato operativo que debe convertirse en una prueba.

La matriz termina con uno de estos tres veredictos:

• NO APTO: falta al menos un control crítico o el riesgo no está acotado. El agente permanece sin acceso real o con permisos mínimos de lectura en un entorno de prueba.
• PILOTO ACOTADO: los controles críticos están cubiertos, pero faltan datos suficientes para autorizar autonomía amplia. Se limita el volumen, la duración, los usuarios y las acciones.
• APTO CON CONTROL: las pruebas críticas y el umbral acordado están superados, existe seguimiento y se ha ensayado la parada. No significa "autonomía ilimitada" ni elimina la revisión periódica.

La palabra importante es evidencia. "Lo hemos visto funcionar" no es evidencia suficiente. Un conjunto versionado de casos, una captura del permiso, una traza completa, un informe de evaluación, una prueba de restauración o un acta de aprobación sí lo son.

Qué significa auditar un agente de IA

Auditar un agente no es preguntarle si sabe hacer su trabajo. Los modelos pueden describir con mucha seguridad un procedimiento que después no siguen. Tampoco es repetir diez veces la misma instrucción hasta obtener diez respuestas correctas. Una auditoría examina el sistema completo y trata de refutar la hipótesis de que es seguro y útil.

El objeto de la revisión incluye al menos siete capas:

• Propósito: la decisión empresarial que justifica el sistema.
• Información: datos de entrada, memoria, fuentes de conocimiento y salidas.
• Capacidad de acción: herramientas, permisos, credenciales y límites.
• Comportamiento: calidad, consistencia, abstención y manejo de incertidumbre.
• Operación: rendimiento, coste, dependencias, observabilidad e incidentes.
• Personas: aprobación, supervisión, formación, derechos y responsabilidades.
• Gobierno: documentación, proveedores, cambios, cumplimiento y retirada.

Esta visión encaja con las funciones Govern, Map, Measure y Manage del NIST AI RMF. Primero se establecen responsabilidades y reglas. Después se entiende el contexto y el impacto. A continuación se mide el comportamiento. Por último se decide cómo tratar y vigilar el riesgo. Saltar directamente a "Measure" produce evaluaciones bonitas de un sistema cuyo objetivo, propietario o límites nadie ha definido.

La AEPD advierte en sus orientaciones sobre IA agéntica que conocer una herramienta como usuario no basta para tomar decisiones informadas cuando entra en tratamientos de datos personales. Hay que comprender sus fundamentos, alcance, límites y aplicación. Ese cambio de perspectiva es fundamental: no se audita una conversación, se audita un tratamiento y una capacidad de actuar.

La auditoría tampoco debe confundirse con un examen jurídico aislado. Puede haber una base legítima para el tratamiento y, aun así, un diseño inseguro. Puede haber una buena arquitectura técnica y, aun así, un propósito desproporcionado. Puede haber controles adecuados y, aun así, una experiencia que engañe al usuario sobre si habla con una persona. La revisión útil conecta las capas.

Cómo usar la matriz 4 x 8 sin convertirla en burocracia

Cada prueba de esta guía contiene cuatro elementos:

1. Pregunta: qué debe poder responder el equipo.
2. Evidencia mínima: qué documento, registro o ejecución demuestra la respuesta.
3. Criterio de paso: qué condición permite marcar la prueba como superada.
4. Corrección: qué hacer si no se cumple.

La puntuación se registra de 0 a 3:

No todos los puntos pesan igual. Las pruebas marcadas como críticas actúan como puertas: si puntúan 0 o 1, el agente no debe ejecutar acciones sensibles en producción. Sumar muchos controles menores no compensa la ausencia de revocación de credenciales, trazabilidad o parada.

La sesión de auditoría funciona mejor con cuatro perfiles presentes: responsable del proceso, persona que integra el sistema, responsable de seguridad o protección de datos cuando corresponda, y usuario que realizará o supervisará el trabajo. La demostración se ejecuta con datos sintéticos o debidamente preparados, nunca improvisando con información real de clientes.

Guarda un expediente mínimo con fecha, versión del agente, versión del modelo, prompts o políticas relevantes, herramientas disponibles, conjunto de evaluación, resultados, excepciones aceptadas, responsables y fecha de revisión. Cuando cambie cualquiera de esas piezas, decide qué pruebas deben repetirse.

Bloque 1: problema, alcance y línea base

Un agente puede ejecutar perfectamente una tarea que no merece automatizarse. Este bloque evita optimizar un proceso innecesario, ambiguo o imposible de medir.

Prueba 1. Existe una decisión de negocio concreta

Pregunta: ¿qué resultado cambia si el agente funciona? "Usar IA" no es un objetivo. "Preparar una propuesta de respuesta para cada solicitud que cumpla estas condiciones" sí lo es, porque define una unidad de trabajo y una salida observable.

Evidencia mínima: ficha de una página con disparador, entrada, salida, usuario, frecuencia, responsable y condición de finalización. Debe separar lo que el agente decide de lo que solo transporta o transforma.

Criterio de paso: dos personas ajenas al desarrollo interpretan del mismo modo cuándo empieza la tarea, cuándo termina y qué queda fuera. El responsable del proceso acepta por escrito esa definición.

Corrección: reducir el caso de uso. Si la descripción contiene varias decisiones unidas por "y", conviene dividirlas. Un primer agente fiable suele resolver una parte estrecha del flujo y entregar el resto a una persona o a una automatización determinista.

Prueba 2. Hay una línea base comparable

Pregunta: ¿cómo se realiza hoy el trabajo y con qué resultado? Sin línea base, cualquier ahorro, mejora o deterioro será una impresión.

Evidencia mínima: muestra temporal suficiente del proceso actual con volumen, tiempo de ciclo, revisiones, incidencias, coste directo y resultado útil. No hace falta medir veinte indicadores. Hace falta medir los que justifican el proyecto.

Criterio de paso: el equipo conoce el valor anterior a la IA y puede repetir la medición después. La definición de cada indicador no cambia a mitad de la comparación.

Corrección: observar primero el proceso manual. Durante un periodo acordado, registrar entradas, salidas, excepciones y horas. Si el negocio no puede medir la situación actual, todavía no puede demostrar que la automatización la mejora.

Prueba 3. El daño máximo está descrito

Pregunta: ¿qué es lo peor que puede ocurrir si el agente se equivoca una vez, cien veces o durante una hora sin ser detectado?

Evidencia mínima: mapa de impacto con personas afectadas, datos expuestos, importe potencial, comunicaciones emitidas, obligaciones incumplidas y tiempo de recuperación. Debe contemplar la repetición automática, no solo el error unitario.

Criterio de paso: existe un límite técnico que mantiene el daño posible dentro de lo aceptado. El límite puede ser de importe, destinatarios, operaciones por minuto, tipo de registro o duración.

Corrección: retirar capacidad de acción, introducir aprobación o reducir volumen. La frase "el modelo casi nunca hace eso" no limita el impacto. Un control debe seguir funcionando precisamente cuando el modelo toma una mala decisión.

Prueba 4. Los criterios de éxito y parada no se contradicen

Pregunta: ¿el agente puede cumplir su métrica dañando otra parte del negocio? Un sistema premiado por responder rápido puede contestar sin comprobar. Uno premiado por cerrar incidencias puede cerrarlas antes de resolverlas.

Evidencia mínima: objetivo principal, métricas de seguridad y condiciones de parada. Cada optimización debe acompañarse de al menos una restricción que evite el atajo obvio.

Criterio de paso: el equipo puede explicar qué resultado desea y qué resultado no aceptará para conseguirlo. Las alertas cubren ambos.

Corrección: rediseñar la métrica. Combinar velocidad con corrección, volumen con reclamaciones, automatización con tasa de revisión y ahorro con coste total de excepción.

Bloque 2: datos, fuentes y memoria

Los agentes no trabajan con "los datos de la empresa" como una masa uniforme. Consultan fuentes concretas, arrastran fragmentos a un contexto, generan nuevas salidas y a veces guardan memoria. Cada movimiento cambia el riesgo.

Prueba 5. Existe un inventario de datos de extremo a extremo

Pregunta: ¿qué datos entran, dónde se procesan, qué sale y qué se conserva? Incluye datos introducidos por usuarios, recuperados del CRM, enviados al proveedor del modelo, escritos en registros y almacenados en memoria.

Evidencia mínima: diagrama de flujo con sistema origen, finalidad, campos, proveedor, región cuando sea relevante, retención y destinatario. Debe distinguir producción, pruebas y observabilidad.

Criterio de paso: no aparece en una traza ningún campo que falte en el inventario. Cada dato tiene una finalidad identificada y un propietario.

Corrección: instrumentar una ejecución controlada, revisar payloads y actualizar el mapa. Después eliminar los campos que no sean necesarios antes de discutir medidas más complejas.

Prueba 6. La minimización se aplica antes de enviar

Pregunta: ¿el agente recibe solo la información que necesita para esa decisión? Ocultar campos en la interfaz no sirve si el payload completo viaja al modelo.

Evidencia mínima: comparación entre el registro original y el contexto efectivo entregado al agente, con reglas de filtrado, seudonimización o enmascarado.

Criterio de paso: cada campo puede justificarse por la tarea. Identificadores, historiales, notas internas y adjuntos se excluyen por defecto y se incorporan solo cuando una regla explícita los necesita.

Corrección: crear una capa de preparación de datos. Nunca delegar la minimización al propio modelo mediante una instrucción del tipo "ignora lo sensible". Si el dato ya entró en el contexto, el control llegó tarde.

Prueba 7. Las fuentes tienen autoridad, fecha y conflicto resuelto

Pregunta: ¿cómo sabe el agente qué fuente prevalece cuando dos documentos discrepan? Una base de conocimiento sin gobierno convierte versiones antiguas en respuestas plausibles.

Evidencia mínima: catálogo de fuentes con propietario, fecha, vigencia, nivel de autoridad y regla de desempate. Las respuestas de prueba deben poder señalar la fuente utilizada.

Criterio de paso: ante una contradicción sembrada deliberadamente, el agente utiliza la fuente prioritaria o se abstiene. No mezcla fragmentos hasta fabricar una tercera versión.

Corrección: retirar documentos obsoletos, añadir metadatos y filtrar la recuperación por vigencia. Para políticas críticas, recuperar primero el documento canónico y hacer que el sistema cite la sección utilizada.

Prueba 8. La memoria se puede inspeccionar, corregir y borrar

Pregunta: ¿qué recuerda el agente entre sesiones y durante cuánto tiempo? La memoria puede mejorar continuidad, pero también consolidar un error, mezclar clientes o conservar información innecesaria.

Evidencia mínima: especificación de memoria con clave de separación, contenido permitido, tiempo de vida, procedimiento de corrección y borrado. Prueba con dos identidades distintas.

Criterio de paso: la información de un usuario no aparece en la sesión de otro; un dato corregido deja de influir; el borrado produce un efecto verificable; la memoria no sustituye al sistema de registro oficial.

Corrección: separar por entidad, acortar retención y guardar hechos estructurados en vez de conversaciones completas. Si no se puede explicar qué recuerda, desactivar la memoria persistente hasta poder gobernarla.

Bloque 3: identidad, permisos y herramientas

Un agente con acceso a herramientas es software con capacidad de actuar. Su identidad técnica y sus permisos importan más que el tono de sus respuestas.

Prueba 9. El agente tiene identidad propia y revocable (crítica)

Pregunta: ¿actúa con una cuenta de servicio identificable o con la cuenta personal de alguien? Compartir credenciales impide atribuir acciones y complica la retirada.

Evidencia mínima: identidad separada por entorno, propietario, método de autenticación, fecha de rotación y procedimiento de revocación. Los registros deben mostrar esa identidad.

Criterio de paso: se puede desactivar al agente sin bloquear al usuario humano ni cambiar credenciales de toda la empresa. Una prueba de revocación impide nuevas acciones inmediatamente o dentro del plazo documentado.

Corrección: crear cuentas de servicio o aplicaciones dedicadas, eliminar claves compartidas y centralizar secretos. Nunca guardar una clave en el prompt, el repositorio o una hoja accesible al equipo completo.

Prueba 10. Cada herramienta aplica mínimo privilegio (crítica)

Pregunta: ¿el agente puede hacer más de lo necesario? Poder leer todo el CRM para actualizar una etiqueta es un diseño cómodo, no un diseño seguro.

Evidencia mínima: matriz herramienta-acción-recurso. Debe mostrar métodos permitidos, objetos alcanzables y restricciones. La interfaz real de permisos debe coincidir con el documento.

Criterio de paso: las operaciones fuera de alcance fallan aunque el agente las intente. La seguridad no depende de que el prompt le pida que se porte bien.

Corrección: usar endpoints específicos, vistas limitadas, scopes mínimos, listas de recursos y funciones intermediarias. Cuando un proveedor solo ofrece permisos amplios, colocar una capa propia que valide cada solicitud.

Prueba 11. Las acciones sensibles requieren una puerta externa (crítica)

Pregunta: ¿qué acciones no puede completar el agente por sí solo? Enviar una comunicación delicada, borrar, pagar, firmar, cambiar permisos o decidir sobre una persona exige más que una frase de cautela.

Evidencia mínima: política de aprobación aplicada fuera del modelo, con rol autorizador, información mostrada, caducidad y registro de aceptación o rechazo.

Criterio de paso: el agente puede proponer, pero la herramienta rechaza la ejecución hasta recibir una aprobación válida. Cambiar el prompt no permite saltarse la puerta.

Corrección: dividir preparación y ejecución. El agente crea un borrador estructurado; una persona revisa los datos y la consecuencia; un componente determinista realiza la acción aprobada.

Prueba 12. Las entradas de herramientas se validan de forma determinista

Pregunta: ¿la herramienta acepta directamente lo que redacta el modelo? Los modelos son buenos produciendo estructuras, pero también pueden omitir, inventar o deformar campos.

Evidencia mínima: esquema cerrado, validación de tipos, límites, listas permitidas y tratamiento de errores. Incluye pruebas con campos extra, valores extremos, formatos incorrectos y texto hostil.

Criterio de paso: ninguna entrada inválida alcanza el sistema de destino. La herramienta devuelve un error controlado que no provoca bucles ni una reinterpretación peligrosa.

Corrección: validar antes de ejecutar, normalizar identificadores, limitar longitudes y rechazar lo desconocido. Para importes, fechas, destinatarios y permisos, usar reglas de negocio fuera del modelo.

Bloque 4: seguridad, instrucciones hostiles y acciones encadenadas

Un agente puede recibir instrucciones desde lugares que la empresa no considera instrucciones: un correo, una web, un PDF, una nota del CRM o la descripción de un producto. Ese contenido no debe adquirir autoridad por entrar en el contexto.

Prueba 13. Se separan instrucciones, datos y contenido externo (crítica)

Pregunta: ¿el sistema distingue una regla de la empresa de una frase encontrada en un documento? La inyección de prompt explota precisamente la confusión entre ambos niveles.

Evidencia mínima: arquitectura de mensajes y política de confianza. Pruebas con documentos que intentan cambiar el objetivo, pedir secretos, añadir destinatarios o ordenar el uso de otra herramienta.

Criterio de paso: el contenido externo se trata como dato. No puede elevar permisos, modificar políticas ni alterar el destinatario de una acción. Los intentos quedan registrados.

Corrección: aislar el contenido, etiquetar su procedencia, reducir herramientas disponibles durante su análisis y validar cualquier acción con políticas externas. No existe una frase mágica que elimine por sí sola la inyección.

Prueba 14. Los secretos nunca forman parte del contexto

Pregunta: ¿las claves, tokens o contraseñas pueden aparecer en el prompt, la memoria o la salida? Pedir al modelo que no los revele no evita que hayan sido expuestos.

Evidencia mínima: gestor de secretos, referencias opacas y escaneo de trazas. La herramienta usa la credencial sin entregársela al modelo.

Criterio de paso: una prueba que solicita repetir instrucciones, volcar contexto o mostrar configuración no recupera secretos. Los registros tampoco los contienen.

Corrección: mover credenciales al runtime, rotar cualquier secreto expuesto y sanear logs. Dar a cada integración su propia clave con alcance mínimo y caducidad razonable.

Prueba 15. Las acciones encadenadas tienen presupuesto y profundidad

Pregunta: ¿cuántos pasos, llamadas, mensajes o modificaciones puede ejecutar un objetivo? La autonomía sin presupuesto puede convertir un error pequeño en una cascada.

Evidencia mínima: límites de pasos, tiempo, coste, herramientas y reintentos. Simulación de un caso que nunca encuentra una respuesta y otro que provoca llamadas circulares.

Criterio de paso: el flujo termina de forma segura al alcanzar el límite, conserva el estado necesario y escala a una persona. No reintenta indefinidamente ni duplica acciones.

Corrección: introducir contadores, idempotencia, tiempos máximos y estados terminales. Diferenciar entre reintentar una consulta y repetir una acción externa.

Prueba 16. El agente resiste abuso de volumen y de objetivo

Pregunta: ¿un usuario puede utilizar el sistema para enviar spam, consultar masivamente, agotar presupuesto o convertir una función legítima en otra distinta?

Evidencia mínima: límites por usuario y organización, cuotas, detección de patrones y pruebas de objetivo fuera de alcance.

Criterio de paso: las solicitudes abusivas se bloquean o degradan antes de causar coste o daño. Existe una alerta con información suficiente para investigar.

Corrección: aplicar rate limiting, presupuesto por tarea, listas de capacidades y verificación de identidad. El modelo puede ayudar a clasificar, pero el límite debe ejecutarlo la infraestructura.

Bloque 5: calidad, evaluaciones y abstención

Una prueba manual demuestra una posibilidad. Una evaluación repetible permite comparar versiones y estimar dónde falla. La documentación de modelos de OpenAI explica que los snapshots permiten fijar una versión para mantener un comportamiento más consistente. La guía oficial de evaluaciones permite convertir criterios y datos de prueba en comparaciones repetibles entre modelos y configuraciones.

Prueba 17. Existe un conjunto de casos representativos

Pregunta: ¿las pruebas reflejan el trabajo real o solo ejemplos escritos por quien construyó el agente? Los desarrolladores conocen la solución y tienden a crear entradas demasiado limpias.

Evidencia mínima: conjunto versionado con casos frecuentes, poco frecuentes, incompletos, contradictorios y fuera de alcance. Las muestras deben anonimizarse o sintetizarse de forma fiel.

Criterio de paso: el responsable del proceso confirma la representatividad y puede señalar qué proporción corresponde a cada tipo de tarea. El conjunto no se modifica después de ver el resultado sin registrar el cambio.

Corrección: muestrear trabajo histórico, entrevistar a usuarios y añadir excepciones reales. Separar un conjunto de ajuste de otro de validación para no optimizar únicamente contra las preguntas conocidas.

Prueba 18. La respuesta correcta está definida de antemano

Pregunta: ¿cómo se decide si una salida es buena? "Suena razonable" produce evaluaciones cambiantes y favorece al resultado que más gusta en ese momento.

Evidencia mínima: rúbrica por caso con hechos obligatorios, errores críticos, tolerancias, formato y decisión esperada. Cuando no hay una única respuesta, se definen propiedades aceptables.

Criterio de paso: dos revisores aplican la rúbrica con discrepancias pequeñas o resueltas mediante una regla. Los errores críticos están separados de las preferencias de estilo.

Corrección: convertir el criterio experto en ejemplos y reglas observables. Para extracción, comparar campos; para clasificación, etiquetas; para redacción, hechos, tono, prohibiciones y necesidad de escalado.

Prueba 19. Se evalúan herramienta, decisión y resultado por separado

Pregunta: cuando una tarea falla, ¿sabemos si fue por la interpretación, por la llamada a la herramienta o por el efecto final? Una tasa global oculta la causa.

Evidencia mínima: métricas por etapa: selección de herramienta, argumentos, respuesta del sistema, decisión posterior y resultado empresarial. Una traza relaciona todas las etapas mediante un identificador.

Criterio de paso: cada fallo del conjunto de evaluación se asigna a una causa accionable. El equipo puede cambiar una capa sin confundir su efecto con otra.

Corrección: instrumentar pasos, guardar versiones y crear pruebas unitarias para la lógica determinista. No usar al modelo para validar su propia salida como único árbitro.

Prueba 20. El agente sabe abstenerse y escalar (crítica)

Pregunta: ¿qué hace cuando faltan datos, las fuentes discrepan o la petición está fuera de alcance? Responder siempre no es disponibilidad, es incapacidad para reconocer límites.

Evidencia mínima: clases de abstención, umbrales, mensaje al usuario y cola de escalado. Casos diseñados para que la respuesta correcta sea no actuar.

Criterio de paso: el agente detiene la acción en los casos críticos y entrega a la persona el contexto mínimo para decidir. No inventa información para completar campos obligatorios.

Corrección: entrenar la política de salida con ejemplos negativos, exigir fuentes o campos y dar una vía clara de escalado. Medir tanto la falsa confianza como la abstención innecesaria.

Bloque 6: coste, rendimiento y fallos de dependencias

Un sistema puede ser correcto y no ser viable. También puede funcionar con una latencia que obliga al usuario a repetir, generando duplicados. La operación debe medirse por tarea completa, no solo por llamada al modelo.

Prueba 21. El coste se conoce por tarea y por excepción

Pregunta: ¿cuánto cuesta completar una unidad útil, incluida la recuperación de errores, el almacenamiento, la revisión humana y las integraciones?

Evidencia mínima: desglose por escenario normal, largo, reintento y escalado. Incluye consumo del modelo, búsquedas, herramientas, infraestructura y tiempo humano.

Criterio de paso: existe un presupuesto por tarea y una alerta antes de rebasarlo. El coste puede compararse con la línea base del bloque 1.

Corrección: reducir contexto, usar reglas donde no hace falta razonamiento, elegir modelos por etapa, almacenar resultados reutilizables y limitar ciclos. No abaratar eliminando los controles que detectan errores caros.

Prueba 22. La latencia tiene un objetivo y una experiencia de espera

Pregunta: ¿cuánto puede esperar el usuario y qué ocurre mientras tanto? Una tarea de treinta segundos puede ser aceptable si es asíncrona y transparente, pero desastrosa si parece bloqueada.

Evidencia mínima: percentiles de tiempo por etapa, timeout, estado visible, confirmación y política de cancelación. Probar conexiones lentas y proveedores degradados.

Criterio de paso: el usuario no necesita repetir para saber si la tarea está en curso. El sistema evita dobles ejecuciones y ofrece una salida cuando supera el plazo.

Corrección: mover tareas largas a una cola, devolver identificador, comunicar progreso real y hacer idempotente la operación. Optimizar después de saber qué dependencia consume el tiempo.

Prueba 23. Cada dependencia tiene un modo de fallo ensayado

Pregunta: ¿qué pasa si el modelo, el CRM, el correo, el vector store o la API no responde? "Volver a intentar" puede ser correcto para una lectura, pero peligroso para un cobro o un envío.

Evidencia mínima: tabla dependencia-fallo-impacto-respuesta y pruebas de timeout, error parcial, credencial caducada, límite de cuota y respuesta corrupta.

Criterio de paso: el sistema falla de forma segura, no pierde el estado y no duplica efectos. La alerta identifica la dependencia y la tarea afectada.

Corrección: aplicar circuit breakers, colas de mensajes, idempotency keys, compensación y recuperación manual documentada. Diferenciar operación confirmada, rechazada y estado desconocido.

Prueba 24. Existe un límite operativo independiente del modelo

Pregunta: ¿qué detiene el sistema si empieza a consumir o actuar fuera de patrón? La orden de parada no puede depender del mismo componente que se ha desviado.

Evidencia mínima: límites de gasto, frecuencia, concurrencia, volumen y destinatarios aplicados por infraestructura. Prueba deliberada de sobrepaso.

Criterio de paso: el límite corta la ejecución y genera una alerta antes del impacto máximo definido en la prueba 3.

Corrección: añadir cuotas duras, presupuesto acumulado, límites horarios y kill switch. El panel debe mostrar consumo útil por tarea, no solo tokens o llamadas.

Bloque 7: control humano, trazabilidad y reversión

"Hay una persona supervisando" solo es un control si esa persona recibe la información adecuada, dispone de tiempo, puede rechazar y sabe qué ocurrirá después. Un botón de aprobar colocado por costumbre puede convertirse en una formalidad sin revisión real.

Prueba 25. La aprobación muestra consecuencias, no solo texto

Pregunta: ¿el revisor ve exactamente qué acción, sobre qué registro y con qué destinatario va a ejecutarse? Revisar un resumen redactado por el propio agente puede ocultar el dato equivocado.

Evidencia mínima: pantalla o payload de aprobación con valores críticos tomados del sistema origen, diferencias respecto al estado actual y consecuencia prevista.

Criterio de paso: una persona detecta en la prueba cambios de destinatario, importe, alcance o permiso sin abrir otras cinco herramientas. Aprobar y rechazar quedan registrados.

Corrección: diseñar una vista de decisión, resaltar cambios y recuperar datos críticos de forma independiente. Para lotes, permitir revisar muestras y límites, pero no esconder el volumen total.

Prueba 26. La traza reconstruye la tarea completa (crítica)

Pregunta: ¿podemos explicar después qué recibió el sistema, qué versión decidió, qué fuente usó, qué herramientas llamó, quién aprobó y qué cambió?

Evidencia mínima: identificador de correlación, eventos temporales, versiones, entradas y salidas sanitizadas, usuario, aprobación y resultado externo. Los registros protegen datos y secretos.

Criterio de paso: un tercero reconstruye un caso de prueba sin depender de la memoria del desarrollador. Puede distinguir propuesta, intento, confirmación y fallo.

Corrección: instrumentar antes de ampliar autonomía. Registrar eventos estructurados en vez de grandes bloques de texto. Definir retención, acceso y alertas sobre ausencia de trazas.

Prueba 27. La parada funciona durante una ejecución (crítica)

Pregunta: ¿se puede impedir que el agente inicie nuevas acciones y cancelar las pendientes? Apagar la interfaz no detiene necesariamente las colas o procesos en curso.

Evidencia mínima: procedimiento y prueba del kill switch, incluyendo workers, cron, webhooks, colas y credenciales. Debe identificar qué acciones no pueden cancelarse una vez enviadas.

Criterio de paso: la prueba de parada produce un estado conocido, conserva evidencia y no reanuda por sí sola. Solo un rol autorizado puede restablecerla.

Corrección: centralizar la bandera de ejecución, pausar consumidores, revocar credenciales si hace falta y crear una lista de comprobación de contención. Ensayar la parada antes del lanzamiento.

Prueba 28. La reversión se ha probado, no supuesto (crítica)

Pregunta: ¿cómo se deshace una acción incorrecta o se vuelve a la versión anterior del sistema? No todas las acciones son reversibles, y esa diferencia debe diseñarse.

Evidencia mínima: plan por tipo de efecto, backup cuando corresponda, versión anterior desplegable y prueba de restauración. Para lo irreversible, existe prevención reforzada y compensación.

Criterio de paso: el equipo revierte un cambio de prueba dentro del objetivo de tiempo acordado y verifica el estado final. La copia de seguridad por sí sola no cuenta si nunca se restauró.

Corrección: introducir versionado, operaciones compensatorias y doble aprobación. Si una acción no puede deshacerse, reducir quién, cuándo y cuántas veces puede ejecutarla.

Bloque 8: gobierno, cumplimiento, proveedores y salida

La producción empieza, no termina, el día del lanzamiento. Modelos, APIs, precios, personas y requisitos cambian. Sin un propietario y una fecha de revisión, el agente envejece en silencio.

Prueba 29. Hay un responsable operativo y uno de negocio

Pregunta: ¿quién decide si el agente sigue siendo útil y quién responde cuando falla? "El proveedor" no cubre las decisiones internas ni la relación con las personas afectadas.

Evidencia mínima: matriz de responsabilidades con operación, seguridad, datos, aprobación de cambios, atención de incidencias y retirada. Incluye sustitutos y horarios.

Criterio de paso: una alerta real llega a una persona capaz de actuar. El responsable de negocio revisa resultados y excepciones, no solo disponibilidad técnica.

Corrección: asignar nombres y tiempos de respuesta. Integrar la supervisión en una rutina existente. Un sistema sin dueño debe perder autonomía hasta recuperarlo.

Prueba 30. La clasificación regulatoria y la transparencia se revisan por uso

Pregunta: ¿qué normas, derechos y deberes son relevantes para este contexto? El AI Act de la Unión Europea utiliza un enfoque basado en riesgo, y su aplicación no se decide por llamar "agente" al producto.

Evidencia mínima: análisis del caso de uso, personas afectadas, datos, sector, decisión y grado de autonomía. Incluye información al usuario cuando corresponda y canal para ejercer derechos o reclamar.

Criterio de paso: el análisis está hecho por una persona competente, cita la versión vigente de las fuentes y diferencia obligación de recomendación. No utiliza esta checklist como certificado de cumplimiento.

Corrección: solicitar revisión jurídica o de protección de datos cuando el riesgo lo requiera. Evaluar también si procede una EIPD. La AEPD mantiene recursos específicos para evaluaciones de impacto.

Prueba 31. Los cambios de modelo, prompt o herramienta pasan regresión

Pregunta: ¿qué ocurre cuando se actualiza una dependencia? Cambiar un modelo puede mejorar el promedio y empeorar justo el caso crítico que sostenía una regla de negocio.

Evidencia mínima: inventario de versiones, changelog, evaluación previa, comparación, aprobación y plan de vuelta atrás. Las versiones de producción deben ser identificables.

Criterio de paso: ningún cambio relevante llega directamente a producción. El conjunto de regresión incluye fallos históricos y puertas críticas.

Corrección: fijar versiones cuando el proveedor lo permita, separar configuración de código y automatizar las evaluaciones. Si una dependencia cambia sin aviso suficiente, reducir su responsabilidad o colocar una interfaz estable.

Prueba 32. La empresa puede salir del proveedor y retirar el agente

Pregunta: ¿qué datos, prompts, flujos, evaluaciones y registros puede recuperar la empresa? ¿Cómo se eliminan accesos y copias cuando termina el servicio?

Evidencia mínima: inventario de activos, formatos de exportación, propiedad, dependencias, plan de migración, destrucción y revocación. Incluye credenciales y webhooks olvidados.

Criterio de paso: una simulación de salida permite reconstruir el servicio esencial o volver al proceso anterior sin perder datos operativos. Se puede demostrar qué acceso quedó revocado.

Corrección: documentar desde el inicio, evitar formatos cerrados para los datos críticos y mantener una ruta manual. La dependencia técnica puede aceptarse, pero debe ser consciente, valorada y reversible dentro de un plazo razonable.

Cómo interpretar el resultado

La puntuación máxima es 96, pero el número no decide por sí solo. Primero se revisan las puertas críticas: pruebas 9, 10, 11, 13, 20, 26, 27 y 28. Todas deben alcanzar al menos 2 antes de autorizar acciones sensibles. Para un sistema con impacto alto, algunas deberían alcanzar 3 y acompañarse de una revisión especializada.

Después puede utilizarse esta orientación:

Los umbrales son una herramienta de priorización, no una verdad universal. Una recepción de llamadas que toma un recado no tiene el mismo impacto que un agente que modifica condiciones contractuales. La decisión debe considerar el daño máximo, la reversibilidad y los derechos de las personas.

Hay otra señal útil: la deuda de evidencia. Una puntuación 1 significa que existe una explicación sin prueba. Diez controles "declarados" pueden sonar maduros en una reunión y fallar a la primera incidencia. La prioridad del piloto debe ser convertir las declaraciones críticas en pruebas reproducibles.

El informe final debería caber en una tabla con prueba, puntuación, evidencia, excepción, responsable y fecha. Los anexos guardan capturas, trazas y resultados. Así dirección puede leer la decisión sin perder el detalle técnico necesario para defenderla.

Tres ejemplos hipotéticos de aplicación

Los siguientes ejemplos no son casos de clientes ni resultados atribuidos a YAG. Son escenarios hipotéticos para mostrar cómo cambia la auditoría según el efecto del agente.

Ejemplo 1: agente que clasifica solicitudes comerciales

El agente recibe formularios, identifica servicio, urgencia y sector, crea un registro y propone el siguiente paso. Al principio solo etiqueta y redacta. No envía mensajes.

Los controles dominantes son separación entre datos e instrucciones, minimización, calidad de clasificación, duplicados y trazabilidad. El conjunto de evaluación incluye mensajes breves, solicitudes ambiguas, spam, datos incompletos y texto que intenta ordenar al sistema que ignore sus reglas.

Puede pasar a un piloto acotado con permiso para crear borradores y etiquetas. Para enviar una respuesta necesita aprobación hasta demostrar que respeta destinatario, tono, hechos y política comercial. La métrica no es "leads procesados". Es tiempo hasta revisión, precisión por categoría, duplicados, escalados correctos y contactos válidos que reciben atención.

En este tipo de proyecto, la orquestación mediante automatizaciones con n8n permite separar pasos deterministas, decisiones del modelo y acciones externas. Esa separación hace más fácil evaluar y corregir.

Ejemplo 2: agente que extrae datos de facturas

El agente lee documentos y propone proveedor, fecha, base, impuestos, total y centro de coste. El sistema contable valida formatos y duplicados. Una persona aprueba antes de contabilizar.

El riesgo no está solo en leer mal un número. También puede mezclar páginas, interpretar una proforma como factura, duplicar un documento o exponer datos en registros. Las pruebas deben utilizar distintos formatos, escaneos defectuosos, abonos, varias divisas, documentos con instrucciones incrustadas y totales deliberadamente inconsistentes.

El criterio correcto se define por campo. Un error de descripción no pesa como un error de importe o proveedor. La herramienta contable rechaza si los totales no cuadran, el proveedor no existe o la referencia ya fue utilizada. El modelo propone; las reglas deciden si la propuesta puede avanzar.

El piloto puede reducir trabajo de transcripción sin conceder capacidad de pago. Añadir pagos sería otro caso de uso, con permisos, aprobación y daño máximo completamente diferentes.

Ejemplo 3: recepcionista con IA conectada a telefonía y CRM

El sistema atiende una llamada, identifica la intención, consulta horarios o disponibilidad y registra el recado. Puede transferir a una persona, pero no decide sobre casos sensibles ni confirma algo que no está en una fuente autorizada.

Aquí la experiencia y la transparencia importan. La persona debe entender con quién interactúa cuando sea exigible y disponer de una salida humana. Las pruebas incluyen ruido, interrupciones, acentos, datos dictados, menores, urgencias, peticiones fuera de servicio y llamadas maliciosas. También se prueba qué ocurre si falla la transcripción, el CRM o la transferencia.

La memoria se limita al contexto necesario. Los datos sensibles no se repiten innecesariamente. Los registros distinguen audio, transcripción, extracción, decisión, transferencia y resultado. La integración de una centralita virtual con CRM y automatización exige diseñar el flujo completo, no colocar un modelo delante del teléfono.

El sistema puede ser útil con autonomía baja: informar desde fuentes controladas, tomar recados y enrutar. Ampliar a reservas, cambios o decisiones requiere nuevas pruebas y permisos.

Preguntas que una empresa debe hacer a su proveedor

Una buena propuesta no necesita esconderse detrás de nombres de modelos. Estas preguntas revelan si el servicio está diseñado para operar o solo para impresionar en una demo:

1. ¿Qué acción exacta realiza y qué parte seguirá siendo humana?
2. ¿Qué datos salen de nuestros sistemas y a qué proveedores llegan?
3. ¿Con qué identidad y permisos accede a cada herramienta?
4. ¿Qué acciones son imposibles sin aprobación externa al modelo?
5. ¿Cómo separáis instrucciones de contenido no confiable?
6. ¿Qué conjunto de evaluación utilizáis y quién define la respuesta correcta?
7. ¿Qué ocurre si una API no responde después de ejecutar una acción?
8. ¿Cómo evitáis duplicados, bucles y consumo ilimitado?
9. ¿Qué podemos reconstruir a partir de los registros de una incidencia?
10. ¿Cómo se detiene y cuánto tarda en dejar de actuar?
11. ¿Qué se puede revertir y cuándo se probó la restauración por última vez?
12. ¿Qué cambia en precio y dependencia si aumenta el volumen?
13. ¿Quién responde operativamente después de la entrega?
14. ¿Cómo se revisan cambios de modelo, prompts y herramientas?
15. ¿Qué activos y datos recibimos si dejamos el servicio?

Una respuesta clara no garantiza calidad, pero una respuesta vaga a permisos, pruebas o salida es una señal suficiente para frenar la autonomía. "Utilizamos el modelo más avanzado" no responde a ninguna de esas preguntas.

Errores frecuentes al pasar de prototipo a producción

Dar acceso amplio para avanzar más rápido

Durante una demo parece práctico utilizar la cuenta del fundador, una clave con permisos totales o el buzón completo. Después esa excepción se convierte en arquitectura. Cuando el sistema ya depende del acceso, reducirlo cuesta más.

La solución es crear desde el primer día una identidad de prueba parecida a la futura identidad de producción. Si el API no permite mínimo privilegio, el equipo descubre el problema antes de construir alrededor de él.

Medir solo si termina la tarea

Un agente puede completar la tarea equivocada. Puede registrar un lead, pero en la cuenta incorrecta. Puede enviar un correo, pero inventar una condición. Puede extraer un total, pero omitir que el documento era un presupuesto.

Por eso la evaluación separa decisión, argumentos, herramienta y efecto. "Éxito" técnico no equivale a resultado correcto.

Utilizar el modelo como único control

Pedir al agente que revise su respuesta, sea prudente o no revele secretos puede mejorar el comportamiento medio. No constituye una frontera de seguridad. Los límites de permiso, volumen, esquema y aprobación deben vivir fuera del modelo.

El modelo puede aconsejar. La infraestructura debe impedir.

Conservar todo por si acaso

Guardar prompts, respuestas, documentos y trazas completas facilita depuración, pero también acumula datos y riesgo. La observabilidad debe diseñarse con minimización, acceso y retención. No todo lo útil durante una incidencia necesita conservarse indefinidamente.

La pregunta no es "¿registramos?" sino "¿qué evento necesitamos reconstruir, con qué detalle y durante cuánto tiempo?".

Confundir supervisión con aprobación automática

Si una persona recibe cientos de propuestas iguales, terminará aprobando por patrón. El control humano pierde sustancia aunque siga apareciendo en el diagrama.

Conviene reservar aprobación para lo que requiere juicio, presentar diferencias relevantes, agrupar con límites y medir el tiempo real de revisión. Si nadie puede revisar el volumen, hay que reducir autonomía o mejorar el control determinista.

Promover cambios sin regresión

Un prompt parece una configuración inocua, pero puede alterar selección de herramientas, abstención y formato. Una actualización de modelo también. Sin versiones y conjunto de regresión, el equipo descubre el cambio en producción.

La salida profesional es sencilla: versión identificable, evaluación automática, revisión de puertas críticas y vuelta atrás preparada.

Qué debe contener el expediente de producción

No hace falta producir cien páginas. Hace falta que las decisiones importantes sean recuperables. Un expediente mínimo incluye:

• ficha de objetivo y alcance;
• responsable operativo y de negocio;
• línea base y métricas de resultado;
• mapa de datos, fuentes, memoria y retención;
• matriz de permisos por herramienta;
• política de acciones sensibles y aprobación;
• modelo, versión, configuración y dependencias;
• conjunto de evaluación, rúbricas y resultados;
• pruebas adversarias y de fallo de dependencias;
• presupuesto y límites operativos;
• esquema de trazas y alertas;
• procedimientos de parada, reversión y recuperación;
• análisis regulatorio aplicable y revisiones especializadas;
• plan de cambio, revisión periódica y retirada.

Cada documento debe tener fecha y propietario. Lo más importante no es el formato, sino que describa el sistema que realmente está desplegado. Una política perfecta que no coincide con los permisos efectivos empeora la auditoría porque genera falsa confianza.

La guía de la AEPD sobre requisitos para auditorías de tratamientos con IA aporta una referencia útil cuando hay datos personales. Para riesgos específicos de IA generativa, el perfil NIST AI 600-1 ayuda a ampliar la identificación y gestión. Esta matriz no reemplaza ninguno de esos trabajos: traduce parte de sus principios a preguntas operativas para un sistema con herramientas.

Un piloto de 30 días que produzca evidencia

Un piloto útil no es un mes de acceso libre para ver qué ocurre. Es un experimento con alcance, comparación y puertas de salida. El calendario puede adaptarse al riesgo y al volumen, pero esta secuencia evita que la presión por lanzar sustituya a la validación.

Días 1 a 5: observar y acotar

El equipo selecciona una unidad de trabajo, documenta el proceso actual y recoge una muestra representativa. Se identifican excepciones, datos sensibles, sistemas implicados y daño máximo. Durante estos días el agente no actúa sobre producción. Puede procesar copias controladas o datos sintéticos.

La entrega no es una presentación. Es una ficha de alcance, una línea base, un mapa de datos y una primera lista de acciones permitidas y prohibidas. Si el proceso tiene demasiadas variantes para describirlas, se reduce el caso. El objetivo de la primera semana es conseguir una frontera clara, no demostrar potencia.

Días 6 a 10: construir controles antes de autonomía

Se crean la identidad de servicio, los permisos mínimos, los esquemas de entrada, los límites y las trazas. Las acciones sensibles se dividen en propuesta y ejecución. También se prepara el interruptor de parada y se comprueba que afecta a workers, colas y disparadores.

La tentación habitual es dejar los controles para el final, después de comprobar que el agente "entiende". Eso obliga a reconstruir integraciones y genera excepciones. Diseñar primero la capacidad máxima permitida hace que el prototipo se parezca al sistema que se pretende operar.

Días 11 a 15: evaluar sin tocar el resultado real

El agente procesa el conjunto de evaluación en modo sombra. Recibe entradas equivalentes a las reales, pero sus decisiones no producen efectos. El equipo compara la salida con la rúbrica y separa errores de interpretación, recuperación, herramienta y formato.

Se añaden casos adversarios y de abstención. Cada corrección se prueba contra el conjunto completo, no solo contra el ejemplo que la motivó. Así se evita solucionar una excepción rompiendo otra. Al terminar, la empresa debe conocer la distribución de fallos y no únicamente una media agregada.

Días 16 a 23: piloto limitado y revisado

Solo si las puertas críticas están superadas, se autoriza un volumen pequeño, usuarios concretos y acciones reversibles. Las propuestas delicadas requieren aprobación. Cada día se revisan errores, abstenciones, coste, latencia, duplicados y trabajo humano de supervisión.

La revisión humana también se mide. Si validar cada propuesta tarda casi tanto como hacerla, el sistema todavía no genera la ventaja prevista. Puede necesitar una mejor interfaz, criterios más claros o un caso de uso distinto. Ocultar ese coste produce un retorno ficticio.

Los límites del piloto deben poder consultarse en configuración y en los sistemas destino. Un documento que dice "máximo veinte" no sirve si técnicamente puede ejecutar dos mil. Cualquier excepción al alcance se registra con motivo, responsable y fecha de caducidad.

Días 24 a 27: provocar fallos y recuperar

Se desconectan dependencias en un entorno controlado, se caduca una credencial, se fuerza un timeout y se introduce una respuesta inválida. Después se prueba la parada, la restauración y la vuelta a la versión anterior. El objetivo no es evitar toda incidencia, sino saber si el sistema contiene el daño y deja una situación comprensible.

También se simula la ausencia del responsable habitual. Si nadie más puede interpretar la alerta o aplicar el procedimiento, existe una dependencia humana no documentada. El resultado del ejercicio actualiza manuales, límites y asignaciones.

Días 28 a 30: decidir, no celebrar

El cierre reúne la matriz, la comparación con la línea base, los fallos abiertos, el coste total, el tiempo de supervisión y la opinión de los usuarios. La decisión puede ser ampliar, mantener el piloto, reducir capacidades o retirar. Todas son respuestas válidas si se apoyan en evidencia.

Una aprobación debe indicar versión, alcance, límites y fecha de revisión. No se aprueba "el agente" para siempre. Se aprueba una configuración concreta para una tarea concreta. Si después se incorpora una herramienta, otro tipo de dato o una nueva acción, se reabre la parte correspondiente de la auditoría.

Este calendario no garantiza que treinta días sean suficientes. Un proceso con poco volumen necesitará más tiempo para reunir casos. Uno de alto riesgo exigirá análisis especializados. Su utilidad está en ordenar el aprendizaje: primero frontera y línea base, después controles, luego evaluación y solo entonces autonomía limitada.

Preguntas frecuentes

¿Qué es una auditoría de un agente de IA?

Es una revisión estructurada del objetivo, los datos, los permisos, la seguridad, la calidad, los costes, el control humano y el gobierno del agente antes de autorizarle acciones reales. No consiste en comprobar que una demo funciona. Busca evidencias de que el sistema también se comporta de forma aceptable ante información incompleta, instrucciones hostiles, errores de herramientas, cambios y límites.

¿Una checklist garantiza que el agente cumple el RGPD o el AI Act?

No. La matriz ayuda a descubrir riesgos y evidencias ausentes, pero no sustituye un análisis jurídico, una evaluación de impacto ni una auditoría formal cuando sean exigibles. La clasificación depende del uso, los datos, el sector, las personas afectadas y el grado de autonomía. Debe revisarse con fuentes vigentes y profesionales competentes.

¿Cuándo puede un agente actuar sin aprobación humana?

Cuando la acción es de bajo impacto, está acotada, es reversible, queda registrada y tiene límites de volumen y coste. Etiquetar una solicitud puede admitir autonomía. Pagar, borrar, firmar, cambiar permisos o comunicar algo sensible requiere una puerta humana o determinista proporcionada al riesgo.

¿Cuántas pruebas debe superar para pasar a producción?

No basta con sumar. Las ocho pruebas críticas deben alcanzar al menos el nivel probado antes de permitir acciones sensibles. Después se valora el conjunto y el daño máximo. Un agente con 90 puntos y sin parada real sigue siendo no apto para producción.

¿Qué diferencia hay entre una prueba funcional y una evaluación de IA?

La prueba funcional confirma que una integración ejecuta una acción. La evaluación comprueba si la decisión que conduce a esa acción es correcta en una muestra representativa y adversaria. Un webhook puede funcionar al cien por cien mientras el agente elige mal cuándo activarlo.

¿Hay que repetir la auditoría al cambiar de modelo?

Sí, al menos las pruebas afectadas. También al cambiar prompts, fuentes, herramientas, reglas o permisos. Conviene fijar versiones, conservar fallos históricos en el conjunto de regresión y comparar antes de promover el cambio.

¿Se puede auditar un agente que ya está desplegado?

Sí. Si existe riesgo, primero se contiene: se reducen permisos, se limita volumen y se verifica la parada. Después se revisan trazas, incidentes y configuración, se reconstruye una línea base y se ejecutan pruebas en un entorno separado. No debe utilizarse producción como laboratorio para acciones irreversibles.

De la demostración a un sistema defendible

El valor de un agente no está en parecer humano ni en ejecutar muchos pasos. Está en resolver una tarea útil dentro de límites que la empresa entiende y controla. La madurez aparece cuando el equipo puede decir "esto no lo hará", "aquí debe parar" y "esta es la evidencia" con la misma claridad con la que explica lo que sí automatiza.

Las 32 pruebas convierten una conversación abstracta sobre confianza en trabajo concreto. Algunas descubrirán que el caso todavía no merece IA. Otras revelarán que basta una automatización determinista. En los proyectos que sí necesitan razonamiento y herramientas, la matriz permite ampliar autonomía sin saltarse la responsabilidad.

Si todavía estás decidiendo qué motor utilizar, la guía de GPT-6 Astra frente a Claude Fable 5.1 y los modelos de trabajo diario explica cómo comparar calidad, coste y riesgo con tareas reales, en lugar de elegir por marca o por una tabla de benchmarks.

Si quieres revisar un flujo real, YAG puede ayudarte a delimitar el caso, conectar sistemas y construir las pruebas antes de promoverlo. El punto de partida no es comprar un agente. Es traer un proceso, sus datos, sus excepciones y el resultado que necesitas mejorar. Puedes ver nuestro enfoque de inteligencia artificial aplicada a empresa o contarnos el proceso para preparar una revisión técnica y operativa.

Última revisión: 8 de septiembre de 2026. Esta guía es informativa. No constituye certificación, asesoramiento jurídico ni garantía de ausencia de riesgo.