Cómo desarrollé revisiones de seguridad basadas en agentes en Databricks

Ya contábamos con automatización en algunas partes de nuestro proceso de revisión de seguridad. Era útil, pero no reducía lo suficiente el trabajo manual.

Seguía viendo el mismo patrón en la cola: una integración de rutina que utilizaba un diseño familiar podía estar al lado de una arquitectura genuinamente novedosa y de alto riesgo, ambas esperando el mismo recurso escaso, un revisor experimentado.

El problema no era que nuestra automatización existente hubiera fallado. Simplemente había alcanzado sus límites. Seguíamos dedicando tiempo de expertos a tareas predecibles, lo que dejaba menos espacio para las decisiones que realmente requerían un criterio experto.

Así que creé una capa basada en agentes para ampliar lo que ya teníamos. El objetivo no era reemplazar el proceso ni a las personas detrás de él. Era ayudar al sistema a comprender una solicitud, aplicar nuestros estándares, solicitar la información faltante y reconocer cuándo era necesario que interviniera una persona.

La primera versión basada en agentes se centró en una sola ruta de revisión. Mi equipo vio el patrón más amplio y lo expandió a un conjunto de agentes que ahora admiten partes adicionales de nuestro proceso de recepción y revisión de seguridad. Creé esa primera versión completamente en Databricks, la misma plataforma que utilizan nuestros clientes.

Por qué era importante la plataforma

Pude avanzar rápidamente porque las piezas principales ya estaban disponibles en un solo entorno.

Unity Catalog proporcionó un espacio gobernado para nuestros estándares de seguridad, datos de solicitudes, pruebas de respaldo, decisiones y resultados del sistema. Los modelos fundacionales alojados en Databricks proporcionaron la capa de modelos para la clasificación y el razonamiento. Lakeflow Jobs orquestó los flujos de trabajo basados en notebooks en computación serverless. Databricks Apps ofreció la experiencia de recepción y el panel ejecutivo.

Cómo encajan las piezas

A grandes rasgos, una solicitud fluye a través de la plataforma en una sola ruta continua, donde cada paso lee y escribe en las mismas tablas gobernadas:

1. Recepción - Una aplicación conversacional basada en Databricks Apps convierte una descripción en lenguaje sencillo en una solicitud estructurada y adjunta cualquier documento de diseño de respaldo.
2. Razonamiento - Los modelos fundacionales alojados en Databricks (Claude Haiku, Sonnet y Opus) clasifican la solicitud, evalúan el riesgo y redactan los requisitos, siempre basándose en nuestros estándares de seguridad. Haiku se encarga de la clasificación ligera, Sonnet maneja la mayor parte del trabajo de revisión y Opus se reserva para el razonamiento más complejo.
3. Orquestación - Lakeflow Jobs ejecuta los agentes de revisión en computación serverless, trasladando cada solicitud a través de sus etapas según una programación.
4. Sistema de registro - Unity Catalog almacena los estándares, los datos de las solicitudes, las pruebas, los resultados de los modelos y las decisiones como tablas gobernadas, con un único modelo de permisos y linaje para todo ello.
5. Observabilidad - Una segunda Databricks App lee esas mismas tablas para informar sobre el volumen, la combinación de riesgos, la tasa de automatización y el tiempo ahorrado.

Esto nos dio un modelo operativo y de gobernanza coherente en todos los datos, modelos, flujos de trabajo y aplicaciones. En lugar de ensamblar servicios separados con diferentes permisos, registros y rutas de datos, pude concentrarme en la lógica de revisión y la experiencia del usuario.

La diferencia práctica fue la velocidad. Tuve un sistema en funcionamiento en menos de dos horas. Hacer lo mismo conectando servicios separados habría llevado semanas.

No todas las revisiones necesitan el mismo camino

La mayoría de las colas de seguridad contienen tanto solicitudes predecibles como excepciones genuinas.

Una integración que utiliza un patrón de autenticación aprobado y no maneja datos confidenciales no requiere la misma decisión que un servicio expuesto a Internet que procesa información confidencial con un amplio acceso administrativo. Sin embargo, una cola tradicional puede enviar a ambos por la misma ruta manual.

Mi objetivo no era automatizar cada revisión. Automatizaba las partes repetibles y preservaba el criterio humano donde el riesgo o la incertidumbre eran mayores.

Eso llevó a una regla simple: automatización para casos bien comprendidos dentro de criterios explícitos; personas para decisiones novedosas, de alto riesgo o ambiguas.

Una mejor puerta de entrada

La calidad de la revisión depende de la información disponible al inicio.

Los formularios estáticos esperan que los solicitantes sepan qué revisión necesitan, que comprendan la terminología de seguridad y que anticipen las pruebas que solicitará un revisor. Cuando no es así, la solicitud llega incompleta y la revisión comienza con otra ronda de preguntas.

Creé una aplicación de recepción conversacional con Databricks Apps. El solicitante describe lo que intenta hacer en lenguaje sencillo. La aplicación identifica la ruta de revisión probable, hace preguntas de seguimiento que dependen del contexto y puede utilizar un documento de diseño integrado como contexto de respaldo. Destaca la información faltante y proporciona una indicación de riesgo preliminar antes de que se cree una solicitud formal.

Una vez que tiene suficiente contexto, crea una solicitud estructurada para el equipo de seguridad.

La aplicación también tiene un modo de consulta basado en nuestros estándares de seguridad. No todas las preguntas tienen que convertirse en un ticket. Los equipos pueden obtener orientación mientras aún están dando forma a un diseño y abrir una revisión formal solo cuando esté justificado.

Esta se convirtió en una de las partes más útiles del sistema. Permite que las personas avancen más rápido, en lugar de tratar la cola como la única forma de interactuar con el equipo de seguridad.

Cómo funcionan los agentes

Detrás de la aplicación de recepción hay una colección de agentes especializados implementados en Databricks Notebooks y orquestados con Lakeflow Jobs.

Evité deliberadamente crear un único agente con amplia autoridad para actuar como revisor de seguridad. Cada agente tiene una responsabilidad delimitada: recopilar contexto, evaluar el riesgo, vincular la solicitud con los estándares pertinentes, redactar requisitos, gestionar el seguimiento o preparar la derivación a una persona.

Siete agentes especializados, cada uno con una tarea

Se trata de un conjunto de agentes especializados (no un agente general ni un único script), cada uno con una tarea específica, orquestados como trabajos programados detrás de la aplicación de recepción:

• Agente de recepción - Gestiona la puerta de entrada conversacional: identifica la ruta de revisión, hace preguntas que dependen del contexto y arma una solicitud estructurada.
• Agente de evaluación de riesgos - Asigna un nivel de riesgo con pruebas de respaldo y, de forma predeterminada, asigna un nivel más alto cuando la información está incompleta.
• Agente de requisitos - Vincula una solicitud con los estándares relevantes y redacta requisitos específicos de la implementación para casos bien comprendidos.
• Agentes de revisión especializados - Manejan tipos de solicitudes que necesitan una lógica dedicada, como el modelado de amenazas de extensiones de navegador y la evaluación de proveedores externos.
• Agente de validación - Crea una lista de verificación de validación por elemento para solicitudes de mayor riesgo antes de que se cierre cualquier proceso.
• Agente de flujo de trabajo - Maneja el trabajo de seguimiento: aclaraciones, recordatorios, seguimiento de confirmaciones y derivaciones a personas.
• Agente de aprendizaje - Compara periódicamente las ediciones de los revisores con el resultado original para identificar mejoras en las instrucciones (prompts) y los estándares.

Cada agente tiene una responsabilidad delimitada, por lo que su comportamiento sigue siendo inspeccionable y verificable, y un cambio en uno no afecta silenciosamente a otro.

El sistema primero evalúa el riesgo de la solicitud y registra las pruebas que respaldan esa evaluación. Una etiqueta de riesgo por sí sola no es suficiente.

Cuando la información falta o es contradictoria, el sistema solicita aclaraciones o dirige la solicitud a un revisor. No realiza inferencias para llegar a una aprobación.

Para solicitudes de rutina, los agentes generan requisitos basados en la arquitectura real y los estándares aplicables, en lugar de devolver plantillas genéricas. El solicitante acepta esos requisitos y proporciona las pruebas necesarias. Las solicitudes elegibles de riesgo bajo y medio pueden completarse a través de la ruta automatizada una vez que se cumplan los criterios y las validaciones definidos.

Un ejemplo

Tomemos un caso común: una integración interna que utiliza un patrón de inicio de sesión único (SSO) aprobado y no maneja datos confidenciales. En lugar de una plantilla genérica, el agente de requisitos genera elementos específicos y verificables vinculados a esa arquitectura; por ejemplo:

• Autenticarse a través del proveedor de identidad aprobado y deshabilitar cualquier credencial local o compartida.
• Restringir la integración a los alcances de acceso mínimos necesarios y documentarlos.
• Enviar los registros de la aplicación y de acceso a la canalización de registro central.
• Confirmar el nivel de clasificación de datos y volver a realizar una revisión antes de que se introduzca cualquier dato confidencial.

El solicitante acepta estos elementos y adjunta las pruebas. Si todo es correcto y el caso cumple con los criterios de elegibilidad, se puede completar a través de la ruta automatizada.

Las solicitudes de alto riesgo, críticas, inusuales o ambiguas se dirigen a una persona. Para entonces, el revisor recibe un resumen estructurado, pruebas de respaldo, las normas aplicables y cualquier pregunta que quede pendiente.

Los agentes también se encargan de gran parte del trabajo administrativo relacionado con la revisión: recopilar detalles faltantes, enviar recordatorios, realizar el seguimiento de las confirmaciones y escalar el caso cuando alguien solicita ayuda. Se recurre a un revisor cuando una solicitud se vuelve ambigua o requiere criterio personal.

La automatización funciona dentro de las reglas que definimos. Las personas mantienen el control sobre las excepciones y las decisiones de gran impacto.

Cómo hacer que el sistema sea confiable

La parte más difícil no fue lograr que un modelo generara una respuesta, sino hacer que esa respuesta estuviera acotada, fuera revisable y resultara adecuada para la acción.

Los agentes se basan en nuestras normas de seguridad. Las evaluaciones de riesgos deben incluir pruebas de respaldo. La falta de contexto genera un seguimiento o un escalamiento, no una suposición optimista. La finalización automatizada se limita a criterios y clases de solicitudes predefinidos. El flujo de trabajo registra las entradas, las salidas, las pruebas y las decisiones asociadas a cada solicitud.

Cómo se ve esto en la práctica

Tres elementos hacen que sea seguro actuar en función de una decisión automatizada:

• Clases de solicitudes predefinidas. Solo las categorías bien conocidas y de menor riesgo son aptas para la finalización automatizada; por ejemplo, una integración interna de rutina en un patrón aprobado que no maneje datos confidenciales. Cualquier elemento fuera de esas clases se dirige a una persona de forma predeterminada.
• Pruebas aceptables. Una decisión es tan buena como lo que la respalda. Por pruebas nos referimos a artefactos concretos y verificables: un documento de diseño vinculado, un nivel de clasificación de datos declarado, o la configuración y las referencias que demuestren que se ha implementado un control aprobado. Una afirmación sin pruebas se trata como información faltante.
• Una evaluación rechazada o incierta. Cuando faltan pruebas o estas son contradictorias, el sistema no hace suposiciones. De forma predeterminada, recurre al nivel de riesgo más conservador, publica una solicitud de aclaración específica o entrega la solicitud a un revisor con las preguntas pendientes adjuntas. No llega a aprobarse de ninguna manera.

Los comentarios de los revisores nos ayudan a identificar brechas y a mejorar el sistema con el tiempo. Utilizamos esas correcciones para perfeccionar nuestras normas, prompts y la lógica del flujo de trabajo, en lugar de permitir que los agentes cambien el comportamiento en producción por su cuenta.

Esos controles importan más que el modelo en sí. Un modelo sólido puede mejorar el razonamiento, pero la confianza proviene del sistema que lo rodea: un alcance claro, pruebas explícitas, un escalamiento conservador y la autoridad humana que le da un peso real al riesgo.

Hacia dónde lo llevó mi equipo

Creé la primera versión basada en agentes para mejorar una ruta de revisión. Mi equipo reconoció que el mismo patrón podría servir para mucho más.

Ampliaron la arquitectura a otros tipos de solicitudes, reforzaron los flujos de trabajo, mejoraron la forma en que los agentes aplican nuestras normas y agregaron los controles necesarios para el uso diario. Lo que comenzó como un único flujo de trabajo basado en agentes se ha convertido en un sistema compartido que el equipo sigue desarrollando.

Yo lo inicié, pero el sistema adquirió valor porque el equipo lo hizo operativo y lo hizo suyo.

Como creador, me enorgullece que la primera versión haya funcionado. Como líder, me enorgullece aún más que el equipo haya visto una base que valía la pena ampliar.

Medición de los resultados

Es de esperar que se hable de eficiencia, pero es difícil creerlo sin pruebas.

Creé un panel ejecutivo como otra Databricks App. Lee los mismos datos de Unity Catalog producidos por los flujos de trabajo de revisión y realiza un seguimiento del volumen de solicitudes, la distribución de riesgos, la finalización automatizada, el escalamiento humano, el tiempo de ciclo y el tiempo estimado que ahorran los revisores.

Dado que las métricas provienen de registros operativos, podemos rastrearlas hasta las solicitudes y decisiones que las generaron, en lugar de conciliar manualmente las exportaciones de sistemas independientes.

Esto cambió la conversación con el equipo de liderazgo. Pudimos mostrar dónde la automatización redujo el esfuerzo manual, dónde los revisores siguieron participando y cómo cambió esa combinación con el tiempo.

Los números

El panel realiza un seguimiento de un conjunto constante de medidas, todas derivadas de los mismos registros operativos.

Qué cambió

Las solicitudes de rutina aptas que antes esperaban en la cola durante días ahora pueden completarse en minutos. Los equipos pueden recibir orientación antes de abrir un ticket, y las solicitudes que sí llegan a un revisor lo hacen con un mejor contexto.

Nuestros ingenieros de seguridad pueden dedicar más tiempo a diseños novedosos, riesgos significativos y decisiones que requieren experiencia. La primera revisión también es más consistente porque las solicitudes se evalúan con las mismas normas y requisitos de pruebas. Cuando el sistema tiene dudas, escala el caso.

Esto no es seguridad sin personas. Es un sistema diseñado para aprovechar la atención de los expertos donde tiene el mayor valor.

Lo que me dejó esta experiencia

Agregar revisores puede aumentar la capacidad, pero no elimina el trabajo repetitivo.

El primer paso es separar el proceso del criterio. Automatice los pasos repetibles solo cuando los criterios sean explícitos, el sistema se base en normas reales, se requieran pruebas, se escalen las dudas y se puedan medir los resultados.

No automatice una decisión simplemente porque un modelo pueda generar una respuesta. Automatícela solo cuando el proceso defina cómo es una respuesta aceptable, qué pruebas la respaldan y qué sucede cuando el sistema no está seguro.

Mantenga a las personas a cargo de las excepciones y las decisiones de gran impacto.

Mi intención no era eliminar a los humanos de la revisión de seguridad. Me propuse reducir el tiempo que dedican a tareas que un sistema controlado puede manejar de manera consistente. Desarrollar sobre Databricks nos brindó la base de plataforma para lograrlo. Ver a mi equipo tomar la primera versión, fortalecerla y hacerla suya ha sido la mejor parte.

Comience con la guía multiagente de Databricks y luego adapte el patrón de esta publicación (datos gobernados en Unity Catalog, agentes enfocados en Lakeflow Jobs y una Databricks App como puerta de entrada) en su propio flujo de trabajo de revisión repetible y basado en pruebas.

Cree un sistema multiagente en Databricks Apps

Comience con la guía multiagente de Databricks y luego adapte el patrón de esta publicación (datos gobernados en Unity Catalog, agentes enfocados en Lakeflow Jobs y una Databricks App como puerta de entrada) en su propio flujo de trabajo de revisión repetible y basado en pruebas.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original