Guía

Arquitectura de harness para agentes regulados

Arquitectura práctica: autoridad, alcance de herramientas y datos, política previa a la acción, validación, escalación humana, supervisión y evidencia.

Para arquitectos de plataformas de servicios financieros, responsables de riesgos de IA y equipos de seguridad.

Última actualización: 7 sept 2026 · Versión v1.0 · No es asesoramiento legal.

Descargar la arquitectura de una página (PDF, en inglés) Hable sobre su arquitectura de control de agentes

Respuesta breve

Un harness para agentes regulados conecta la acción propuesta por un agente con una autoridad explícita, un acceso acotado, la evaluación de políticas, la validación y la escalación humana, y después registra el resultado de la ejecución. La arquitectura de referencia de KLA organiza ese trabajo en siete controles.

Arquitectura

El recorrido de la acción

El responsable de negocio concede autoridad → el agente propone una acción → comprobaciones de identidad y alcance → política previa a la acción → validación o decisión humana cuando sea necesario → ejecución controlada → resultado y evidencia.

Aplique la secuencia a cada acción con consecuencias. Establezca límites de red y credenciales a su alrededor, y envíe los fallos operativos al proceso de supervisión y remediación.

Mapa de controles

Siete controles y sus responsables

El mapeo del producto de KLA que aparece a continuación describe las superficies pertinentes. La columna de aceptación es una prueba de despliegue que se debe realizar; no afirma que exista una aplicación en todo el entorno ni una verificación de cliente completada.

Control	Mapeo de KLA	Responsable final	Prueba de aceptación
Autoridad	Agent Registry; identidad de solicitud gobernada	Plataforma y responsable de negocio	Un agente no reconocido o fuera de alcance no puede realizar la acción
Alcance de herramientas y datos	Tool Catalog; Data Boundaries	Plataforma y responsable de datos	Las solicitudes restringidas de herramientas, registros y tenants se rechazan
Política previa a la acción	Policy Builder; KLA Policy Engine	Responsable de la política	Ejercitar allow, warn, require_approval y block en la ruta integrada
Validación	Simulation; comprobaciones específicas del flujo	Revisor independiente	Los resultados no válidos y las transiciones de estado inseguras fallan antes de la publicación
Escalación humana	Decision Desk	Responsable de decisión autorizado	El rechazo y la caducidad impiden que se ejecute la ruta de acción aprobada
Supervisión	Assurance Center; Lineage Explorer	Operaciones y seguridad	Un fallo de control se convierte en un hallazgo asignado con una respuesta
Evidencia	Audit Trail; Evidence Room	Responsable de evidencia y registros	Reconstruir la solicitud, la decisión, la revisión humana y el resultado real de la ejecución

Integración

Defina el límite de aplicación

Enumere cada endpoint de herramienta, credencial, fuente de datos y agente delegado que pueda provocar la acción seleccionada. Dirija la acción gobernada por el punto de control y pruebe las rutas alternativas. Registre cualquier ruta que permanezca fuera de la aplicación.

El entorno anfitrión es responsable del aislamiento de sandbox, el aislamiento de red y el acceso a producción. Una aprobación debe aplicarse a la acción concreta y seguir siendo válida en el momento de la ejecución; especifique el comportamiento cuando cambien los parámetros, la política o la autoridad.

Aceptación

Revise un caso de principio a fin

Use un caso sintético con una lectura permitida, una acción que requiere aprobación y una operación bloqueada. Compruebe el estado posterior a la aprobación, el rechazo, la caducidad y el reintento. Registre los identificadores, la versión de la política, la identidad del revisor y el resultado.

Para las exportaciones selladas, ejecute también el verificador independiente y conserve su resultado. Un registro visible y un paquete verificado correctamente proporcionan evidencias diferentes; etiquete cada una con precisión.

Contexto

Fuente e interpretación

Esta es la propuesta de arquitectura de KLA, informada por la nota del Banco de Inglaterra sobre harness. Sus siete controles son una agrupación de KLA. El artículo complementario explica los seis temas del Banco y el alcance de la nota.

Mapear los controles con los temas de los estándares del Reglamento de IA de la UE Descargar la arquitectura de una página (PDF, en inglés)

Preguntas frecuentes

Preguntas que los compradores deben resolver

¿Un harness sustituye la evaluación del modelo?

La evaluación del modelo sigue formando parte de la validación del sistema. Un harness también necesita pruebas de autoridad, acceso, ejecución de acciones, decisiones humanas y fallos operativos.

¿Qué controla KLA en esta arquitectura?

KLA aporta políticas, decisiones humanas y evidencia para las rutas gobernadas configuradas. Verifique la cobertura de la integración y asigne por separado las responsabilidades de alojamiento, red, credenciales y evaluación a nivel de sistema.

Enlaces