La verdadera razón por la que no le entregas el trabajo a la IA

Las reglas de detección fallan en dos direcciones: pueden ser demasiado amplias y generar alertas de falso positivo para que el Centro de operaciones de seguridad (SOC) las revise, o pueden ser demasiado precisas y pasar por alto actividad maliciosa. De cualquier forma, la solución empieza por comparar lo que la regla detectó con lo que realmente ocurrió.

Si un atacante usa una sesión robada de Microsoft 365 para tomar el control de una cuenta sin activar ninguna detección, la pregunta es qué debería haberlo detectado: una regla existente demasiado precisa, o una que aún no existe. Los LLM pueden ser útiles para este tipo de análisis, cuando se les dan conjuntos de datos grandes y estructurados para trabajar. Esta tarea parecía razonable de delegar: la IA había dado buenos resultados en trabajos similares antes. El modelo regresó rápidamente con un identificador de app de Microsoft 365 tomado de la actividad del atacante y lo calificó como lo bastante distintivo para construir una nueva regla.

La evidencia que encontró el modelo era real, pero la conclusión fue errónea. El modelo marcó el identificador como malicioso porque aparecía en un buzón conocido como comprometido y era poco común en esa organización. Pero el identificador correspondía al cliente de escritorio de Microsoft Outlook, que aparece en actividad legítima en más del 17% de las organizaciones de nuestros clientes. Una detección basada en eso se activa con toda esa actividad legítima.

Figura 1: Comparación de la frecuencia con la que aparece el identificador de Microsoft 365 en una organización frente a toda la base de clientes de Huntress

Los datos eran correctos. El modelo solo los midió contra el denominador equivocado. Es un error básico de delimitación de alcance y ocurre todo el tiempo. Si delimitas mal el alcance, igual obtienes un número real, lo que hace que sea fácil pasarlo por alto. 

También es fácil de verificar. Con un alcance más amplio, esa misma consulta encontró el identificador que en realidad sí era una herramienta maliciosa. Apareció en solo tres organizaciones, no estaba en ningún catálogo de Microsoft y no hacía nada más que reescribir reglas de bandeja de entrada. Esa lógica ahora se usa en una regla de detección activa, con dos verdaderos positivos y ningún falso positivo hasta el momento.

Así que no confíes solo en lo que escribe el modelo; confía en la verificación. Esto aplica mucho más allá de la ingeniería de detección: lo que puedes verificar es lo que puedes delegar.

Muchas personas tienen ciertas tareas que se niegan a delegar a la IA. Algunas están protegiendo el trabajo que más les importa; otras están evitando el trabajo que parece demasiado riesgoso o complicado. Pero la razón de fondo suele ser otra. El trabajo que la gente protege casi siempre es el trabajo que no tiene una forma rápida de verificar. 

La tolerancia al riesgo también importa aquí, y a veces se te impone en lugar de elegirla tú. Una verificación no cambia eso. Lo que cambia son las probabilidades de que una respuesta incorrecta pase desapercibida. Cuesta una revisión. A cambio, obtienes la segunda pasada.

Por qué no ejecutas el ciclo

El consejo estándar es dejar de tratar la IA como una máquina expendedora (una instrucción, un resultado, y te vas) y en su lugar ejecutar un ciclo: generar, verificar, refinar, repetir. Andrej Karpathy llama a la versión rápida de esto el "ciclo de generación-verificación." De lo que se habla menos es de por qué no lo estás ejecutando ya.

Cada vuelta del ciclo cuesta tokens y una revisión. Los tokens pueden escalar con el presupuesto. Tu tiempo no. Y si la revisión cuesta lo mismo que el trabajo, la primera vuelta apenas empata, y la segunda te deja atrás. Entonces tomas tu única oportunidad y te detienes. Las personas que iteran con fluidez han hecho que la revisión sea casi gratis: una prueba, una métrica o una comparación con algo que ya sabes que funciona.

Considera una regla que construimos hace poco: ningún ingeniero la escribió, pero uno definió el alcance, y a partir de ahí el flujo de trabajo agéntico tomó el control para crear un prototipo y probar una nueva regla.  

Para determinar si la regla realmente tenía valor, había que responder estas preguntas:

• ¿Esto ya está cubierto por una o más reglas existentes? 

• ¿Detecta la actividad para la que fue creada? 

• ¿Cuántas alertas generará en un mes?
  

Ninguna de esas preguntas se puede responder gratis, al menos no rápido. Cada una es una verificación que primero hay que definir manualmente. Una vez definida, la IA puede ejecutar cada una como una pasada corta y acotada en lugar de una investigación abierta: lo bastante barata como para gastarla en un borrador funcional. La IA las ejecuta y el analista de detección lee los resultados. Y cada una puede fallar. La primera falló: la mayoría de los nuevos detectores sugeridos ya existían con menor prioridad, así que el trabajo se convirtió en la ampliación de una lista y tres nuevas reglas experimentales para ampliar el alcance. Esa es la verificación ganándose su lugar. Nada de eso resolvió si la regla era segura para implementarse, o si generaría falsos positivos a gran escala. Lo que sí logró fue más pasadas en el mismo tiempo.

Qué hace que un trabajo sea seguro de delegar a la IA

La verificación se ve distinta en cada trabajo: pruebas para un programador, una rúbrica o un lector de confianza para un escritor, un conjunto de datos con respuestas conocidas para un analista, evaluaciones para un equipo que lanza una función de IA, o las preguntas de cobertura y volumen que una nueva detección debe superar. Pero todas logran el mismo objetivo: reducir el riesgo y dar confianza en el trabajo. O el trabajo se hizo correctamente, o los errores salen a la luz por sí solos. Porque la verificación tiene que poder fallar. Una que siempre pasa no es una verificación en absoluto. Así que si falla, sabes qué hacer a continuación.

Hace poco me encontré corrigiendo a un modelo sobre lo mismo una y otra vez; se desviaba de las pautas que le había dado. Probablemente ya hayas pasado por esto. Después de la tercera vez, dejé de repetirme y construí un mecanismo que detecta la desviación de configuración por sí solo. Yo había estado haciendo esa verificación a mano, así que hice que se ejecutara sola. Evalúa algo a mano hasta que el criterio sea lo bastante estable para codificarlo; entonces la máquina lo ejecuta y la atención sube a la siguiente capa. La pila crece, y siempre hay una persona en la cima. Si una tarea que estás vigilando no tiene verificación, construir una suele ser el trabajo de mayor valor, al menos para cualquier cosa que harás más de unas pocas veces. Cada una es una construcción única, y cada una sigue dando frutos. La verificación es el activo.

Figura 2: Ilustración de cómo el ciclo de verificación y criterio amplía el alcance de un flujo de trabajo

Cuando no puedes construir la verificación

A veces la razón por la que no hay verificación es que construir una está fuera de alcance. Durante mucho tiempo hubo un análisis que quise hacer y nunca intenté: una forma de ver cuánto costaba realmente cada una de nuestras detecciones, al determinar cuánto tiempo de analista puede consumir en silencio una regla ruidosa con alertas que no llevan a ningún lado. No lo dejé de lado porque no valiera la pena. Lo dejé de lado porque estaba seguro de que estaba fuera de mi alcance. Ningún sistema único tenía todos los datos. Habría tenido que extraer información de varios lugares que no se comunicaban entre sí, escribir las consultas, procesar la salida, calcular las estadísticas, construir todo un flujo de trabajo y después decidir qué significaba todo eso.

Luego la IA abarató la construcción, y por fin lo tuve listo en alrededor de una semana. La IA escribió las consultas y el trabajo de fontanería que yo solo nunca habría terminado; ahora es una herramienta reutilizable, y deja un informe en un canal que el equipo realmente usa. El proceso tenía una forma: yo decidía qué importaba, la máquina hacía el trabajo pesado en el medio, y yo tomaba las decisiones al final. Kieran Klaassen llama a esto el sándwich de IA: humano en ambos lados, máquina en el medio. Ese es un peldaño de la escalera, la forma que toma cada capa antes de que el juicio quede codificado y subas de nivel. El juicio seguía siendo mío —qué medir, cómo ponderarlo, dónde trazar los límites, qué cuenta como desperdicio que vale la pena recuperar— y también lo era la verificación.

Las dos capas de pan del sándwich tienen que ser reales. Cuando conozco los insumos y sé cómo luce una buena respuesta, el medio se puede inferir. Cuando no puedo decir cómo debería ser el resultado ni cómo lo calificaría, compenso la diferencia en el prompt apilando instrucciones hasta que el modelo básicamente me repite mis propias suposiciones. Si ambos extremos están bien resueltos, la herramienta se queda en su lugar: le da a una persona la evidencia para decidir qué ajustar, qué retirar, qué dejar en paz.

Lo que hizo inusual este caso es que el obstáculo fue la construcción, no la verificación. Aun así, una vez que la IA lo superó, lo que quedó fue el juicio al principio y una verificación al final. Con mucha más frecuencia, la verificación es más difícil que la construcción.

¿Delegar, o simplemente no mirar?

La verificación también es la mitad más fácil de fingir. Desde afuera, delegar la ejecución y delegar el juicio se ven idénticos: misma tarea, mismo modelo. La diferencia está en si todavía puedes distinguir lo bueno de lo malo al final, y en si de verdad miraste. Si sellas la verificación sin revisarla, nunca la ejecutaste en realidad. Luego, cuando una detección defectuosa sale a producción y falla cientos de veces en toda una flota, eres tú quien tiene que explicarlo.

La habilidad se movió

El verdadero trabajo es construir la verificación y luego aprender a vivir del otro lado de ella. Automatizar una habilidad traslada el esfuerzo hacia el juicio, y resulta que hay mucho más de eso de lo que el antiguo trabajo dejaba ver.

Brian Concannon lo dice sin rodeos en More Rules, Less Confidence: el costo de producir una regla cayó a casi cero, y "la parte difícil de la ingeniería de detección nunca fue escribir la regla. Era todo lo que pasa después." Su respuesta es una compuerta: probar cada regla contra datos conocidos como buenos y conocidos como malos antes de lanzarla, para que la basura nunca llegue a producción. Mi enfoque está más arriba en el proceso. La misma verificación es lo que decide si doy una segunda pasada siquiera. Una compuerta protege la producción de mí; una verificación que puedo correr a bajo costo es lo que me permite iterar.

After Automation, de Dan Shipper, plantea un punto relacionado, más general: una vez que cualquiera (usando IA) puede producir el mismo resultado competente, lo escaso se vuelve el gusto, el juicio de qué resultado realmente encaja. Cualquiera puede generar una regla ahora; saber si es la regla correcta, y poder demostrarlo rápido, es lo que sigue ganando valor. Parte de eso es subjetivo: saber qué buscar, y cómo luce un resultado que pasa la prueba, es un juicio en sí mismo. Pero eso ordena las opciones; la verificación decide cuál es correcta. Ese orden solo se sostiene donde existe una respuesta correcta por encontrar. En la escritura, en el diseño, en la mayor parte de lo que describe Shipper, no hay un oráculo, y el gusto tiene la última palabra porque nada río abajo puede anularlo. En el tipo de trabajo donde equivocarse sale caro y es verificable, la verificabilidad va primero.

Lo que conservas cuando entregas la ejecución

Luego está el tipo más difícil de aferrarse, el que va más profundo que el riesgo. Proteges el trabajo que es tu experiencia, porque entregarlo se siente como admitir que nunca fue tan especial. "Ser bueno en mi trabajo" solía significar hacer la tarea con mis propias manos y producir el resultado. Ahora significa saber cómo luce un buen resultado. Entrega la "ejecución" y lo que queda es el juicio. Para muchos oficios, esta fue siempre la mejor mitad, la parte que te hacía valer la pena escuchar; las teclas presionadas eran solo la parte que se veía.

Sin embargo, hay un riesgo real en esa entrega. Si cedes toda la "ejecución", puedes perder el instinto del que se alimenta el juicio; te vuelves peor para detectar una respuesta sutilmente equivocada si nunca produces respuestas tú mismo. Así que haz suficiente trabajo para mantener el ojo entrenado, y deja que la máquina cargue con la mayor parte una vez que la verificación esté construida.

La pregunta que deberías hacerte en su lugar

Probablemente haya algo que todavía no le entregarías a la IA. Quizás es el trabajo en el que eres mejor; quizás es el trabajo que no puedes darte el lujo de arruinar. De cualquier forma, la pregunta que debes hacerte es si lo notarías, rápido, si la respuesta volviera equivocada. Si no lo notarías, te falta una verificación. Sigues siendo dueño del trabajo; solo se ve diferente. Construye la verificación.