Un relato en primera persona publicado en el blog de Databricks describe cómo se reemplazó parte de una cola interna de revisión de seguridad por un sistema multiagente construido enteramente sobre la propia plataforma de la empresa, argumentando que la automatización anterior "simplemente había llegado a su límite" y seguía consumiendo tiempo de revisores expertos en casos predecibles. La publicación, titulada "How I built agent-based security reviews on Databricks," describe un sistema funcional construido en menos de dos horas, frente a lo que el autor dice que habría tomado semanas conectando servicios separados.
La arquitectura consiste en un conjunto de siete agentes especializados en lugar de un único revisor de propósito general: un agente de admisión que gestiona la puerta de entrada conversacional, un agente de evaluación de riesgo que asigna un nivel y por defecto opta por un nivel más alto cuando la evidencia está incompleta, un agente de requisitos que mapea las solicitudes a los estándares, agentes de revisión especializados para casos como el modelado de amenazas de extensiones de navegador y la evaluación de proveedores externos, un agente de validación que construye listas de verificación por elemento, un agente de flujo de trabajo que gestiona recordatorios y escalamientos, y un agente de aprendizaje que compara periódicamente las correcciones de los revisores con la salida de los agentes para identificar mejoras en los prompts y los estándares. El autor escribe que esto fue deliberado: "Deliberadamente evité construir un único agente con amplia autoridad para actuar como revisor de seguridad." Cada agente, según la publicación, tiene una responsabilidad acotada, de modo que su comportamiento "sigue siendo inspeccionable y comprobable, y un cambio en uno no afecta silenciosamente a otro."
La pila nombra cuatro componentes de Databricks que cumplen funciones distintas. Unity Catalog funciona como el sistema de registro, almacenando estándares, datos de solicitudes, evidencia, salidas de modelos y decisiones como tablas gobernadas bajo un único modelo de permisos y linaje. Los modelos fundacionales alojados en Databricks proporcionan la capa de razonamiento, con una división por niveles según la tarea: Claude Haiku para clasificación liviana, Claude Sonnet para "la mayor parte del trabajo de revisión," y Claude Opus "reservado para el razonamiento más pesado." Lakeflow Jobs orquesta los flujos de trabajo de agentes basados en notebooks sobre cómputo serverless. Dos Databricks Apps separadas gestionan las interfaces orientadas a personas: una app de admisión conversacional que convierte solicitudes en lenguaje natural en tickets estructurados, y un panel ejecutivo que lee las mismas tablas de Unity Catalog para reportar sobre volumen, mezcla de riesgo, tasa de automatización y tiempo ahorrado.
En cuanto a la realidad operativa, la publicación es escueta en métricas concretas más allá de la comparación de dos horas frente a semanas de construcción. Afirma que las solicitudes rutinarias elegibles "que antes esperaban en la cola durante días ahora pueden completarse en minutos," pero no adjunta una cifra específica de tiempo de ciclo, un porcentaje de tasa de automatización, ni un volumen de solicitudes — los números subyacentes del panel se describen solo como existentes y se muestran en la publicación con, en palabras del autor, "parte de los datos exclusivamente internos redactados." Quienes evalúen esto como un patrón a replicar obtienen una arquitectura, no una referencia comparativa.
La contrapartida que el autor explicita es de alcance, no de precisión: la automatización se limita a "clases de solicitudes predefinidas" — categorías bien entendidas y de menor riesgo, como una integración interna rutinaria sobre un patrón de inicio de sesión único aprobado que no maneja datos sensibles — y todo lo demás se dirige por defecto a una persona. El sistema trata una afirmación sin sustento como un vacío en lugar de una aprobación: "una afirmación sin evidencia se trata como información faltante," y cuando la evidencia falta o es contradictoria, los agentes publican una solicitud de aclaración o derivan a un revisor "con las preguntas abiertas adjuntas," en lugar de inferir una aprobación. Las correcciones de los revisores retroalimentan los prompts y los estándares, pero explícitamente no permiten que los agentes cambien el comportamiento en producción por su cuenta — una decisión de gobernanza que sacrifica autonomía a cambio de auditabilidad.
Lo que la publicación deja sin resolver para quien intente replicarla es exactamente la parte que un equipo de plataforma necesitaría presupuestar: no hay cifras de costo de inferencia de modelos en los tres niveles de Claude al volumen que sea que maneje esta cola, no hay tasa de error ni de escalamiento falso, y no hay detalle sobre cómo se validaron los umbrales de niveles de riesgo antes de confiarles finalizaciones automatizadas. El relato es un patrón de diseño y una filosofía de gobernanza — agentes acotados, requisitos de evidencia, escalamiento conservador por defecto — no un caso de estudio de costo o precisión.
La conclusión para los equipos que construyen herramientas internas similares: copiar primero la lógica de límites y después la arquitectura — decidir qué clases de solicitudes son elegibles para finalización automatizada y qué cuenta como evidencia aceptable, y solo entonces conectar los agentes, en lugar de construir un revisor general y esperar que su criterio de riesgo se sostenga.