Orca Security Discovery AI reduce el coste de las consultas de seguridad en lenguaje natural

Orca Security Discovery AI ahora convierte preguntas de seguridad en lenguaje sencillo en consultas Sonar utilizando un 93 % menos de tokens de entrada que en su diseño inicial. Orca también informa de costes de consulta un 90 % menores y una latencia un 75 % menor tras reconstruir el sistema sobre Amazon Bedrock.

Estas cifras describen más que una actualización rutinaria de modelo. Orca sustituyó un enorme prompt por un pipeline de nueve etapas que decide cuándo deben encargarse de cada solicitud las reglas, la recuperación, los modelos más pequeños o un razonamiento más profundo.

El resultado pone presión sobre una estrategia común de IA empresarial: colocar cada esquema, ejemplo e instrucción en una única ventana de contexto grande. La experiencia de Orca sugiere que más contexto puede aumentar el coste, reducir la relevancia y ralentizar la aplicación.

Su alternativa trata al modelo de lenguaje como un componente dentro de un compilador de consultas controlado. La coincidencia determinista gestiona las entradas evidentes, la recuperación aporta ejemplos probados y la validación revisa los filtros generados antes de devolverlos.

Este diseño importa porque las consultas de seguridad en lenguaje natural operan sobre información sensible y altamente estructurada. Una respuesta fluida tiene poco valor si el filtro generado apunta al activo equivocado, atraviesa un límite de autorización u omite una condición crítica.

Orca sustituyó un enorme prompt por un pipeline de producción

El cambio central fue arquitectónico: Orca dejó de pedir a un único modelo que comprendiera todo su esquema de seguridad en cada solicitud.

El sistema de consultas Sonar de Orca abarca más de 900 modelos de infraestructura y aplicaciones en la nube. Estos modelos representan recursos como instancias de cómputo, buckets de almacenamiento, identidades, vulnerabilidades y las relaciones que los conectan.

Antes de Discovery AI, los usuarios debían construir filtros JSON precisos. También tenían que conocer los nombres exactos de los modelos, navegar por relaciones anidadas y elegir entre 18 operadores de filtrado.

Ese requisito creó una barrera de usabilidad para analistas que entendían la cuestión de seguridad, pero no el esquema completo de Sonar. Por ello, Orca creó una interfaz de lenguaje natural que traduce la solicitud de un analista en un filtro válido.

La primera prueba de concepto utilizó el enfoque más directo de IA generativa. Orca cargó más de 900 definiciones de modelos, tipos de relaciones y consultas de ejemplo en un único prompt para un modelo grande.

Según la empresa, los socios de diseño y los usuarios internos valoraron positivamente la calidad de los resultados. Sin embargo, el diseño consumía aproximadamente 2 millones de tokens de entrada para una carga de trabajo comparable y tardaba alrededor de 60 segundos.

Las solicitudes complejas también pusieron de manifiesto límites de precisión. Las preguntas que implicaban varios modelos de recursos, relaciones anidadas o múltiples condiciones a menudo requerían refinamiento adicional.

Orca y AWS desarrollaron entonces el pipeline de nueve etapas de producción. Según se informa, ha gestionado miles de consultas diarias desde marzo de 2026, con tiempos de respuesta cercanos a los 15 segundos.

El pipeline comienza combinando la solicitud con el contexto organizativo. Ese contexto puede incluir proveedores de nube conectados, metadatos de la solicitud y detalles necesarios para interpretar el entorno del usuario.

A continuación, un comparador determinista busca identificadores estructurados. Estos incluyen direcciones IP, identificadores CVE, hashes de archivos, nombres de recursos, URL e ID de alertas.

Un identificador coincidente puede activar un filtro predefinido sin una costosa llamada al modelo. Esta vía rápida mantiene el trabajo predecible alejado de un sistema probabilístico.

Las solicitudes que requieren interpretación pasan por una salvaguarda. Orca afirma que esta etapa bloquea intentos de inyección de prompts, preguntas irrelevantes y entradas no compatibles antes de que lleguen a la generación de consultas.

Después, el sistema busca en una biblioteca de ejemplos validados. Los embeddings de Amazon Titan recuperan 20 candidatos semánticamente similares, y Cohere Rerank 3.5 reduce ese conjunto a cinco.

Un selector de modelos reduce los más de 900 modelos Sonar a los relevantes para la solicitud actual. El generador recibe esquemas detallados únicamente para ese grupo más pequeño y sus relaciones.

Anthropic Claude Haiku 4.5 impulsa las etapas de selección y generación. Amazon Nova 2 Lite gestiona las tareas de salvaguarda y validación, donde Orca prioriza una inferencia más rápida y de menor coste.

El filtro generado tampoco se convierte automáticamente en el resultado final. Las comprobaciones estáticas resuelven cada modelo, campo y operador frente a los esquemas seleccionados.

Orca también comprueba el filtro frente a la API de Sonar. Cuando la validación falla, el error identifica el elemento problemático y lo devuelve al generador para su corrección.

Este ciclo convierte la generación en un proceso restringido. El modelo puede proponer un filtro, pero los sistemas deterministas deciden si esa propuesta se ajusta al esquema disponible.

Orca Security Discovery AI reduce el contexto deliberadamente

Orca Security Discovery AI mejoró su economía declarada seleccionando el contexto, no ampliándolo.

El prototipo inicial trataba el esquema completo de Sonar como contexto obligatorio. Esa elección parecía razonable porque el modelo debía comprender cientos de tipos de recursos y sus relaciones.

El problema era que la mayoría de las preguntas afectaban solo a una pequeña parte de ese esquema. Enviar cada definición en cada solicitud aumentaba el uso de tokens sin hacer que cada definición resultara útil.

El selector de modelos de Orca ahora trabaja con descripciones compactas de los modelos disponibles. Cada descripción resume el nombre, propósito, campos importantes y relaciones importantes de un modelo.

El selector identifica qué modelos requiere una pregunta. A continuación, el generador recibe el esquema completo solo de esas selecciones, además de las relaciones necesarias para conectarlas.

Ese cambio redujo el uso de entrada declarado de unos 2 millones de tokens a 140.000 por una carga de trabajo comparable. Representa la reducción indicada del 93 %.

Orca atribuye la reducción de costes del 90 % al menor volumen de tokens y a la asignación de modelos por etapa. Las distintas tareas ya no recurren por defecto al mayor modelo disponible.

Según se informa, la latencia bajó de unos 60 segundos a 15 segundos, una reducción del 75 %. La ruta más rápida sigue conteniendo varias etapas, lo que muestra que el número de etapas por sí solo no determina el tiempo de respuesta.

Una inferencia única y larga puede ser más lenta que varias operaciones acotadas. Las reglas y la recuperación también pueden omitir la generación cuando el sistema reconoce un patrón conocido.

Este es el mecanismo central de las mejoras comunicadas. Orca redujo la cantidad de material que requiere razonamiento profundo y reservó el trabajo generativo para las partes no resueltas de la solicitud.

El diseño de recuperación sigue el mismo principio. La búsqueda semántica top-K pura era rápida, pero Orca descubrió que con frecuencia devolvía ejemplos casi duplicados.

Esos duplicados ocupaban contexto sin aportar mucha cobertura. Maximal Marginal Relevance aumentó la diversidad, pero a veces desplazaba el ejemplo más relevante de la primera posición.

Orca optó por recuperar 20 ejemplos cercanos y reordenarlos hasta cinco. La primera pasada más amplia enfatiza la recuperación, mientras que el reordenamiento centra el contexto final en las coincidencias más sólidas.

Una coincidencia de alta confianza puede reutilizar directamente un filtro ya probado. De lo contrario, los cinco ejemplos muestran al generador cómo se tradujeron previamente preguntas validadas.

Este enfoque se parece más al razonamiento basado en casos que a la generación sin restricciones. El modelo trabaja a partir de un esquema compacto y ejemplos extraídos de comportamientos históricos exitosos.

La arquitectura también mantiene reemplazables las elecciones de modelos. Amazon Bedrock proporciona acceso a varias familias de modelos mediante una capa de servicio compartida, lo que reduce el trabajo de integración independiente.

Esa flexibilidad importa porque el modelo más rápido o preciso para una etapa puede cambiar. Según se informa, Orca puede sustituir el modelo de una etapa sin rediseñar toda la aplicación.

La lección más amplia no es que todos los sistemas necesiten nueve pasos. Es que el contexto debe ganarse su lugar en un prompt de producción.

Los esquemas, ejemplos e historial de conversación imponen costes incluso cuando un modelo admite una ventana de contexto grande. El material irrelevante también puede competir con la evidencia que importa.

Las consultas de seguridad en lenguaje natural siguen necesitando límites estrictos

Una interfaz conversacional reduce la fricción del lenguaje de consulta, pero no puede sustituir la autorización, la validación ni la experiencia en seguridad.

Las consultas de seguridad en lenguaje natural pueden ayudar a un analista a pasar de una idea de investigación a un filtro estructurado. No garantizan que la pregunta en sí esté autorizada o sea completa.

El pipeline de Orca incluye contexto de solicitud, filtrado mediante salvaguardas, generación restringida y dos formas de validación. Esta secuencia reconoce el riesgo de tratar la salida del modelo como una verdad ejecutable.

La evaluación de salvaguardas de Amazon Bedrock puede inspeccionar prompts y respuestas frente a políticas configuradas. Los controles disponibles incluyen filtros de contenido, temas denegados, filtros de información sensible y detección de ataques a prompts.

Sin embargo, una salvaguarda no es un sistema de autorización. Puede clasificar una entrada sin disponer de la identidad del usuario ni de los permisos de recursos necesarios para tomar una decisión de acceso.

La guía de seguridad de AWS establece esa distinción explícitamente. Sus controles de autorización recomiendan aplicar el acceso a los datos fuera del modelo de lenguaje y propagar la identidad del usuario a través de los sistemas conectados.

Esta separación es especialmente importante para los datos de seguridad en la nube. Una consulta podría exponer nombres de activos, vulnerabilidades, relaciones entre cuentas, rutas de red o detalles de configuración interna.

Un asistente con amplio acceso al backend puede convertirse en un intermediario confundido. Esto ocurre cuando un usuario con menos privilegios obtiene información a través de un intermediario con más privilegios.

La arquitectura segura debe restringir qué datos llegan al modelo. También debe garantizar que la consulta Sonar resultante se ejecute con permisos apropiados para el usuario solicitante.

La arquitectura publicada indica que Orca combina las solicitudes con el contexto organizativo y de proveedores de nube. La publicación no ofrece una descripción detallada del aislamiento entre tenants ni de la aplicación de autorización a nivel de usuario.

Esta omisión no demuestra una debilidad. Simplemente significa que los resultados de rendimiento comunicados no deben interpretarse como una evaluación de seguridad completa.

La validación crea otro límite importante. Orca comprueba primero la sintaxis y luego verifica el filtro generado a través de su API de Sonar.

El generador recibe errores estructurados cuando falla una comprobación. Puede revisar el campo, operador o relación específicos en lugar de iniciar otra conjetura sin restricciones.

Este enfoque reduce una clase de alucinación: las referencias a elementos del esquema que no existen. No demuestra que cada consulta válida refleje con precisión la intención del analista.

Un filtro puede ser sintácticamente válido y semánticamente incompleto. Podría seleccionar el modelo correcto, pero omitir una excepción, relación, límite temporal o condición ambiental.

El problema se agrava cuando una solicitud concisa oculta ambigüedad. “Mostrar bases de datos expuestas” puede depender de las definiciones de exposición, tipo de base de datos, accesibilidad de red y riesgo aceptado.

Una interfaz sólida debería revelar las suposiciones o mostrar el filtro generado para su revisión. La publicación de AWS se centra en la generación y validación de filtros, no en la experiencia completa de revisión.

Por lo tanto, los equipos de seguridad deben distinguir entre la validez de una consulta y su corrección investigativa. La primera puede comprobarse automáticamente frente a esquemas, mientras que la segunda suele requerir criterio experto del dominio.

Las salidas deterministas del sistema también merecen atención. Reutilizar un ejemplo validado puede reducir la latencia, pero el umbral de coincidencia debe impedir que preguntas superficialmente similares compartan un filtro inadecuado.

Orca afirma que deriva las consultas de baja confianza a expertos del dominio. Ese proceso de retroalimentación ayuda, aunque su eficacia depende del muestreo, la cobertura de revisión y la calidad de las correcciones.

El acceso mediante lenguaje natural puede ampliar la participación en las investigaciones de seguridad. También desplaza la responsabilidad de los autores de consultas hacia los diseñadores de plataformas que codifican estas salvaguardas.

El verdadero oponente es el diseño de un modelo y un prompt

La comparación más significativa de Orca no es con otro proveedor, sino con el prototipo monolítico al que sustituyó.

Los productos de IA generativa suelen comenzar como un prompt conectado a un modelo capaz. Esa estructura funciona bien para demostrar si un modelo comprende la tarea.

Resulta más difícil de defender cuando la aplicación se enfrenta a tráfico real, esquemas cambiantes, requisitos estrictos de latencia y datos organizacionales sensibles.

La referencia inicial de Orca evidenció esa transición. El prototipo producía respuestas prometedoras, pero enviaba un esquema enorme en cada solicitud y aun así tenía dificultades con relaciones complejas.

El sistema de producción traslada varias responsabilidades fuera del generador. Las expresiones regulares reconocen identificadores exactos, la recuperación encuentra ejemplos, la reclasificación reduce el ruido y los validadores rechazan filtros mal formados.

Esta división genera una inversión importante. Añadir componentes redujo el coste y la latencia generales porque esos componentes evitaron trabajo generativo innecesario.

La canalización también cuestiona las adquisiciones centradas en el modelo. Elegir el modelo más grande no resolvió por sí solo el problema de producción.

En su lugar, Orca asignó modelos según los requisitos de cada tarea. Las etapas con mayor carga de razonamiento recibieron Claude Haiku 4.5, mientras que las etapas más acotadas de filtrado y validación recibieron Nova 2 Lite.

Amazon Titan creó embeddings para la búsqueda semántica. Cohere Rerank 3.5 puntuó los ejemplos recuperados antes de la generación.

Esa combinación añade complejidad operativa. Los equipos deben supervisar varios modelos, el comportamiento de recuperación, los ciclos de validación y las dependencias, en lugar de una sola llamada a API.

Sin embargo, una arquitectura de llamada única oculta la complejidad dentro de un prompt grande. No elimina la gestión de esquemas, la evaluación, la autorización ni el manejo de errores.

Trabajos anteriores de AWS sobre investigaciones en lenguaje natural mostraron un patrón relacionado para Amazon Security Lake. Un agente tradujo las preguntas de los analistas a SQL y permitió análisis de seguimiento sobre registros de seguridad.

La implementación de Orca se dirige a su propio grafo de datos Sonar y a filtros específicos del dominio. Su característica distintiva es la reducción agresiva de esquemas y ejemplos antes de la generación.

Este patrón puede aplicarse más allá de la seguridad en la nube. Los sistemas empresariales suelen exponer cientos de objetos, campos, relaciones y operaciones permitidas.

Las plataformas de atención al cliente, las herramientas de analítica, los portales para desarrolladores y los sistemas de conocimiento afrontan la misma tentación de incluir cada definición en el prompt. Este enfoque puede funcionar durante las demostraciones y fracasar bajo las exigencias económicas de producción.

La alternativa se parece a una canalización de compilador. El sistema analiza la solicitud, identifica estructuras relevantes, recupera precedentes, genera una representación intermedia y la valida.

El modelo de lenguaje gestiona la ambigüedad y la traducción. Los componentes deterministas gestionan las reglas aplicables.

Esta distribución también facilita localizar los fallos. Un equipo puede determinar si la recuperación omitió un ejemplo relevante, la selección dejó fuera un esquema o la validación rechazó un operador.

Un único prompt suele producir una señal de fallo menos útil. La respuesta simplemente es incorrecta, costosa, lenta o una combinación de las tres.

Orca afirma que su sistema de evaluación mide la corrección, la integridad y la equivalencia semántica con consultas de referencia. También divide los resultados en segmentos según las categorías de preguntas y modelos.

Esto es más informativo que una única puntuación agregada. Un sistema puede funcionar bien en conjunto y, aun así, fallar en relaciones multicloud poco frecuentes o en condiciones complejas de vulnerabilidad.

El diseño presiona a otros equipos de IA empresarial para que informen resultados a nivel de sistema. Las puntuaciones de benchmarks de modelos por sí solas no pueden explicar la latencia de la aplicación, la calidad de recuperación, las tasas de validación ni las cargas de trabajo de corrección.

Las cifras son sólidas, pero la evidencia de precisión está incompleta

Las mejoras de coste y latencia son específicas, mientras que la afirmación pública sobre precisión carece del mismo nivel de detalle de medición.

AWS y Orca proporcionan cifras claras de antes y después para tokens, coste y tiempo de respuesta. No publican el conjunto de datos de evaluación, el tamaño de muestra, la tasa de aprobación ni la mejora exacta de precisión.

La publicación afirma que la precisión mejoró para consultas complejas y multimodelo. También describe un sistema de LLM como juez que califica la corrección, la integridad y la equivalencia semántica.

Un LLM como juez utiliza otro modelo para evaluar resultados generados. Puede respaldar una iteración rápida, pero sus conclusiones dependen de la rúbrica, las respuestas de referencia y la fiabilidad del juez.

Orca complementa la puntuación automatizada con especialistas internos y comentarios de clientes. Los responsables de producto, ingenieros de soporte e investigadores de seguridad pueden señalar resultados y añadir ejemplos corregidos.

Según se informa, las consultas de producción de baja confianza entran en una cola diaria de etiquetado. Las correcciones quedan disponibles para ejecuciones posteriores de recuperación sin requerir un despliegue de software.

El director de IA de Orca, Or Gabay, calificó esa interfaz de etiquetado como la inversión de calidad a largo plazo más importante del equipo. La declaración destaca un proceso humano, en lugar de otra actualización de modelo.

Ese proceso resulta creíble como mecanismo de mejora. Aun así, deja varias preguntas sin responder para compradores externos y equipos de ingeniería.

La publicación pública no revela con qué frecuencia la generación alcanza el límite de reintentos. Tampoco informa cuántas solicitudes siguen rutas deterministas o de reutilización de ejemplos.

Tampoco separa la latencia mediana de la latencia de cola. Una cifra de 15 segundos puede describir una carga de trabajo típica mientras oculta solicitudes complejas más lentas.

La expresión “carga de trabajo comparable” necesita mayor definición. Las reducciones de tokens y coste dependen de la combinación de solicitudes, los modelos seleccionados, el comportamiento de caché, la longitud de salida y el número de reintentos.

La reducción de costes comunicada también compara la canalización de producción con la propia referencia inicial de Orca. No es un benchmark frente a otros productos de seguridad en la nube ni sistemas de generación de consultas.

Los lectores deberían tratar los porcentajes como resultados operativos comunicados por la empresa. El estudio de caso de AWS, elaborado conjuntamente, proporciona detalle técnico, pero no es una auditoría independiente.

La fecha de producción de marzo de 2026 y miles de consultas diarias proporcionan una señal útil de adopción. No revelan usuarios únicos, tasas de aceptación, abandonos ni tiempo ahorrado a los analistas.

Estas métricas ayudarían a determinar si el lenguaje natural cambia el comportamiento investigativo. Los menores costes de inferencia importan, pero el valor para el usuario depende en última instancia de decisiones de seguridad mejores y más rápidas.

El ciclo de retroalimentación del sistema introduce otra disyuntiva. Los ejemplos de producción mejoran la cobertura, pero las correcciones pueden codificar interpretaciones inconsistentes salvo que los expertos sigan una política compartida.

Un banco de ejemplos en crecimiento también requiere gobernanza. Los equipos necesitan versionado, revisión de calidad, procedimientos de eliminación y protección contra la entrada de información sensible en ejemplos recuperados.

La guía de AWS para aplicaciones de IA generativa recomienda limitar los datos recuperados antes de que lleguen a un modelo. Sus controles de seguridad hacen hincapié en la propagación de identidad y la aplicación del acceso en la capa de datos.

Estas preocupaciones no invalidan los resultados de Orca. Definen la evidencia necesaria antes de que otra organización trate la arquitectura como una plantilla reutilizable.

La conclusión pública más sólida es acotada, pero útil. Orca informa que la selección de contexto, la especialización de modelos, la recuperación y la validación mejoraron drásticamente su diseño original.

La evidencia no establece una reducción universal para todos los agentes con esquemas extensos. Los equipos deben medir el patrón frente a sus propias cargas de trabajo y requisitos de autorización.

Qué observar tras el despliegue de Orca en Amazon Bedrock

La próxima prueba será si Orca puede preservar la calidad a medida que los esquemas, el comportamiento de los usuarios y las versiones de los modelos sigan cambiando.

La primera señal es publicar detalles de precisión. Un futuro informe técnico debería revelar el tamaño del conjunto de datos, las categorías de consultas, los umbrales de aprobación y la concordancia de la revisión humana.

Los resultados a nivel de segmentos serían especialmente valiosos. Las consultas de relaciones multimodelo parecen ser la categoría más difícil y la prueba más sólida de la arquitectura de Orca.

Una evaluación más transparente reforzaría la afirmación de que el nuevo diseño mejoró la precisión, no solo la eficiencia. El aumento de las tasas de corrección o reintento debilitaría esa conclusión.

La segunda señal es una adopción sostenida en producción. Orca afirma que Discovery AI gestiona miles de consultas diarias, pero los patrones de uso a más largo plazo mostrarán si los analistas confían en la interfaz.

Entre los indicadores útiles se incluyen el uso repetido, los filtros aceptados, las ediciones manuales, el tiempo ahorrado y la proporción de preguntas resueltas sin escalado. Estas medidas conectan el comportamiento del modelo con las operaciones de seguridad.

La tercera señal es cómo gestiona los cambios la canalización. Los esquemas de Sonar evolucionarán, los clientes plantearán preguntas desconocidas y los modelos fundacionales recibirán nuevas versiones.

El diseño independiente del modelo de Orca debería facilitar las sustituciones. Sin embargo, cada cambio sigue requiriendo pruebas de regresión en los límites de recuperación, generación, validación y autorización.

Por ello, el sistema de evaluación continua es tan importante como la arquitectura inicial. Cada prompt, modelo, configuración de recuperación y ejemplo puede alterar el comportamiento en segmentos inesperados.

El sistema también debe seguir siendo útil frente a cambios en el comportamiento de las amenazas. Los analistas pueden vincular las investigaciones al marco de amenazas en la nube mientras los atacantes adoptan nuevas rutas y combinaciones de recursos.

Una biblioteca estática de ejemplos se degradaría en esas condiciones. El ciclo de etiquetado de expertos de Orca pretende mantener el banco de recuperación alineado con las preguntas emergentes.

Para los equipos de ingeniería, la acción inmediata es examinar dónde los prompts grandes contienen material que la mayoría de solicitudes nunca utiliza. Ese material puede corresponder a mecanismos de selección, recuperación o enrutamiento determinista.

Los equipos también deberían separar tres pruebas: si una consulta es válida, si representa la intención del usuario y si el usuario puede acceder a sus resultados.

Orca Security Discovery AI ofrece un caso de producción notable para ese enfoque por capas. Sus mejoras de eficiencia comunicadas son sustanciales, pero su contribución más profunda es un cambio en el diseño de sistemas.

La cuestión ahora es si Orca publica suficiente evidencia operativa para demostrar que esta eficiencia resiste la evolución de los esquemas y el uso adversarial. Esa evidencia determinará si el patrón se convierte en un estándar más amplio para los agentes empresariales.