Cómo protegemos los sistemas internos de Figma con agentes

Cuando se trata de proteger nuestras plataformas internas, las amenazas contra las que nos defendemos en el equipo de ingeniería de seguridad de Figma cambian constantemente. La infraestructura en la nube cambia con frecuencia, los desarrolladores adoptan nuevas herramientas y lo que las personas instalan y ejecutan en sus laptops es diferente cada trimestre (como cuando el equipo de Design Advocates comienza a crear sus propias apps y automatizaciones mediante vibe coding).

Nuestro SIEM, Panther, nos ayuda a mantenernos un paso adelante de estas amenazas al ejecutar una amplia variedad de verificaciones en nuestra infraestructura en la nube, los dispositivos terminales, las apps SaaS y los sistemas de identidad. Cuando detecta un posible problema, publica alertas en Slack y crea un ticket en Asana para que los ingenieros de guardia lo atiendan. Históricamente, estar de guardia implicaba una enorme cantidad de trabajo manual. El principal desafío era recopilar el contexto. Teníamos que averiguar si la alerta se parecía a algo que habíamos visto la semana anterior, si había una solicitud de incorporación de cambios pendiente que pudiera resolver el problema, si en los hilos de Slack se mencionaba algo relacionado, entre muchas otras cosas.

Como muchos equipos, vimos cómo las capacidades de los modelos LLM avanzaron rápidamente durante el último año. Recientemente compartimos cómo Figma se mantiene un paso adelante de las vulnerabilidades con agentes en nuestro código, donde detectamos problemas en cambios de configuración de herramientas sensibles como Okta y AWS gracias a inversiones previas para almacenar su configuración como código. Pero, para reducir de manera significativa el trabajo repetitivo y mejorar la forma en que protegíamos los sistemas internos de Figma, necesitábamos ir más allá del código y construir un sistema nuevo que nos ayudara a gestionar el amplio espectro de problemas que detecta nuestro SIEM.

Comenzamos con un objetivo específico: crear una capa de recuperación que pudiera mostrar el razonamiento previo de los ingenieros de guardia cuando se activara una nueva alerta. Ese proyecto acabó convirtiéndose en un sistema agéntico completo que investiga alertas, consulta registros de auditoría, escribe cambios en el código, abre solicitudes de incorporación de cambios y mejora con el tiempo gracias a su propia memoria. Ha transformado por completo la forma en que trabaja nuestro equipo de seguridad.

La capa RAG: darles memoria a las alertas

Lo primero que desarrollamos fue un sistema de clasificación con recuperación aumentada sobre AWS Bedrock Knowledge Bases y Amazon Kendra. Una vez más, nuestro objetivo inicial era simplemente mostrar el contexto histórico de lo que había ocurrido la última vez que se activó la misma alerta y, quizá, suprimir alertas duplicadas.

Cuando se activa una alerta de Panther, nuestro controlador Lambda la convierte en un documento estandarizado y lo indexa en Kendra. Extraemos campos estructurados de la carga útil sin procesar de la alerta: direcciones IP de p_any_ip_addresses, actores de p_any_usernames y de varios campos de usuario específicos de cada proveedor, e identificadores de cuentas de AWS a partir de los ARN. Estos se convierten en atributos de documento de Kendra que se pueden buscar, junto con el título de la alerta, la gravedad, las etiquetas y las marcas de tiempo:

const attrs: DocumentAttribute[] = [
  { Key: 'alert_id', Value: { StringValue: doc.alert_id } },
  { Key: 'alert_type', Value: { StringValue: doc.alert_type } },
  { Key: 'severity', Value: { StringValue: doc.severity } },
  { Key: 'status', Value: { StringValue: doc.status } },
  { Key: 'created_at', Value: { DateValue: doc.created_at } },
  { Key: 'has_investigation_context', Value: { LongValue: doc.has_investigation_context } },
]

Cuando se activa la siguiente alerta similar, consultamos Bedrock en busca de coincidencias semánticas utilizando el título de la alerta (que, por lo general, es el nombre de la detección seguido del nombre de usuario del actor) como vector principal:

function buildQueryFromAlert(alert: Alert): string {
  return `${alert.data.title}\n\nhas_investigation_context=1`
}

También damos prioridad a la recuperación de alertas que cuentan con un investigation_context, es decir, comentarios que un ingeniero de guardia dejó en Slack sobre lo que encontró. (Una alerta cerrada sin comentarios aporta muy poca información). Capturamos el contexto de la investigación sin cambiar los flujos de trabajo actuales de nuestros ingenieros. Cuando alguien deja una nota en un hilo de alertas de Slack (y contamos con un procedimiento similar para los tickets de Asana), indexamos ese comentario de nuevo en Kendra como contexto de la investigación de la alerta original:

export async function addInvestigationContext(
  alertId: string, contextText: string
): Promise<void> {
  const existingDoc = await findAlertDocument(alertId)
  if (!existingDoc) return

  let updatedContext: string[]
  updatedContext = [...existingDoc.investigation_context, contextText]

  const updatedDoc: AlertDocument = {
    ...existingDoc,
    investigation_context: updatedContext,
    has_investigation_context: 1,
  }
  await reindexDocument(updatedDoc)
}

Cada vez que alguien escribe un comentario útil en un hilo de alertas, hace que el triaje de futuras alertas similares requiera menos esfuerzo. No necesitábamos una herramienta especial de anotación ni un proceso de entrenamiento, porque el flujo de trabajo existente es el proceso de entrenamiento.

Lo que la recuperación podía hacer y hasta dónde llegaba

Nuestro sistema de recuperación genera y publica un resumen (para que lo consulten las personas) en Slack y Asana para cada alerta. Empezó a aliviar casi de inmediato la carga de trabajo de nuestro equipo de guardia. De manera anecdótica, escuchamos que estaba reduciendo el tiempo dedicado a realizar el triaje de alertas y, además, nos permitió implementar algunos cambios programáticos para reducir la fatiga causada por las alertas. Cuando encontrábamos alertas similares con un alto grado de confianza de que eran benignas o duplicadas, reducíamos automáticamente su nivel de gravedad:

if (autoResolutionConfidence >= 7) {
  if (updatedSeverity === 'high' || updatedSeverity === 'critical') {
    await alertsDb.updateAlertSeverity(alert.alertId, 'medium')
  }
}

Solo con este cambio, logramos reducir en un 20 % las alertas que activaban a los ingenieros de guardia.

Con nuestro sistema RAG ya en funcionamiento, comenzamos a pensar cuál sería el siguiente paso, y parecía evidente: incorporar algún tipo de capa agéntica que ayudara a investigar las alertas y resolviera los problemas de forma automática.

Agregar una capa agéntica encima

Utilizamos Tines para crear una capa agéntica sobre nuestro sistema RAG. Cuando Panther detecta un evento, nuestro controlador de flujo de Lambda publica la alerta en Slack junto con el resumen inicial generado por el LLM y las referencias a alertas similares obtenidas de la capa RAG; después, etiqueta automáticamente a @Tines Security Slackbot en el hilo. Los ingenieros de guardia también pueden etiquetar al bot manualmente en cualquier hilo para invocarlo cuando lo necesiten, ya sea para hacer preguntas de seguimiento u obtener otros insights específicos, según lo requiera la situación.

Cuando se etiqueta al bot, un webhook se activa en Tines y lo primero que se ejecuta es el enrutamiento de intención. Un modelo más ligero (como Claude Sonnet) lee todo el hilo de Slack y clasifica la solicitud: ¿se trata del triaje de una alerta, una consulta sobre seguridad de plataformas, una consulta sobre la aprobación de una app u otra cosa? Cada clasificación se dirige a un agente especializado con su propio conjunto limitado de herramientas, una capa de autorización y una indicación del sistema. El agente encargado del triaje de alertas realiza la mayor parte del trabajo, pero contar con agentes independientes para distintas intenciones nos permite dotar a cada uno de un conjunto específico de herramientas, sin el riesgo de tener un agente demasiado amplio con acceso a todo.

El conjunto de herramientas del agente de triaje de alertas

El agente de triaje de alertas (que utiliza un modelo como Claude Opus) es donde ocurre la mayor parte de la investigación. Recibe como contexto el historial completo del hilo de Slack, su propia memoria de orientación (hablaremos de esto más adelante) y un conjunto de herramientas limitado a lo que un ingeniero de seguridad de guardia suele necesitar durante el triaje, entre ellas:

• Okta: obtiene el perfil de un usuario, enumera sus grupos, consulta el historial de inicios de sesión y busca usuarios mediante filtros. Cuando se activa una alerta sobre actividad sospechosa de un actor específico, lo primero que suele hacer el agente es obtener su perfil de Okta para entender quién es y a qué recursos debería tener acceso.
• North Pole Security Workshop (que administra Santa, nuestra herramienta de seguridad para dispositivos terminales): busca reglas, consulta eventos, verifica el estado de sincronización de los hosts y envía reglas a los hosts. Si la alerta está relacionada con un binario bloqueado o una infracción de una política en un dispositivo terminal, el agente puede consultar el ID de firma, revisar el historial de eventos de ese binario y comprobar si otros usuarios están encontrando el mismo bloqueo.
• Wiz: obtiene registros de auditoría, inventario de recursos en la nube, hallazgos de vulnerabilidades, problemas abiertos y recursos expuestos. En el caso de alertas relacionadas con infraestructura en la nube, el agente puede verificar si un recurso marcado presenta vulnerabilidades o configuraciones incorrectas conocidas.
• Slack: lee las respuestas en los hilos, consulta perfiles de usuarios y envía actualizaciones de progreso. El agente lee hilos anteriores vinculados desde alertas similares para recuperar el razonamiento de ingenieros de guardia en ocasiones anteriores y las conversaciones relacionadas.
• Panther: obtiene los detalles de una alerta, los eventos sin procesar que la activaron y la lista de alertas relacionadas. Esto le da al agente acceso a la carga útil estructurada de la alerta, además de lo que se publicó en Slack.
• Modificación de código: abre solicitudes de incorporación de cambios en nuestro repositorio de detecciones de Panther o en nuestro monorepositorio. Hablaremos más sobre esto más adelante.
• Subagente de investigación de Panther: un agente independiente impulsado por un LLM que puede escribir y ejecutar consultas SQL en Snowflake sobre todo nuestro lago de datos de seguridad. Es la herramienta más potente del conjunto y hablaremos de ella a continuación.

Consultar el lago de datos de seguridad

El agente de triaje puede responder muchas preguntas con sus herramientas directas: "¿Quién es este usuario en Okta?”, "¿Qué reglas de Santa se aplican a este binario?”, "¿Este recurso en la nube está en Wiz?” Pero muchas investigaciones requieren profundizar más. ¿Qué estaba haciendo este usuario en AWS durante las dos horas previas a la alerta? ¿Qué procesos se estaban ejecutando en su dispositivo terminal y estaban haciendo algo inusual? ¿Accedió a otras apps o realizó cambios de configuración durante ese período?

Para esas consultas, el agente de triaje delega la tarea a un subagente de investigación independiente. Este subagente (también un modelo como Claude Opus) toma una consulta en lenguaje natural del agente principal y la traduce a SQL de Snowflake. La ejecuta sobre nuestro almacén de datos de Panther, que incorpora registros de auditoría de toda la empresa: AWS CloudTrail, registros del sistema de Okta, eventos de auditoría de GitHub, registros de auditoría de GCP, telemetría de dispositivos terminales de osquery, eventos de Workshop/Santa, hallazgos de Wiz y alrededor de un centenar de tablas más.

El agente principal lo invoca de la misma forma en que le pedirías a un colega que ejecutara una consulta: “Encuentra los inicios de sesión más recientes en Okta del usuario X durante las últimas 48 horas”, “Verifica qué procesos ha estado ejecutando el usuario Y en su dispositivo terminal durante los últimos dos días” o “¿Qué estaba haciendo el usuario Z en AWS EKS entre las 10:21 y las 20:21 UTC del 10 de marzo?”. El subagente determina qué tablas consultar, qué columnas utilizar y cómo filtrar por tiempo.

Esto funciona, pero los esquemas de las tablas pueden ser un poco desordenados. Los nombres de las columnas son inconsistentes entre las distintas fuentes de registros, las claves de unión no están bien documentadas y las funciones de particionamiento temporal varían de una tabla a otra. Sin ayuda, el subagente tendría que dedicar cuatro o cinco consultas solo a descubrir el esquema antes de poder responder la pregunta real. O, peor aún, podría ejecutar una consulta que devolviera resultados incorrectos o incompletos. Más adelante, en la sección sobre la memoria, veremos cómo resolvimos este problema.

Desarrollar y segmentar la memoria del agente

La memoria terminó siendo el elemento que más impacto tuvo en lo útil que se volvió el sistema con el paso del tiempo. Tenemos varios tipos, y mantenerlos separados resultó ser importante.

El corpus RAG es lo que llamamos memoria de casos. Es el sistema que ya describimos: alertas históricas junto con el contexto de investigación proveniente de Slack y Asana. Cuando el agente necesita saber cómo fueron situaciones similares o qué concluyó un ingeniero de guardia sobre un incidente anterior, ahí es donde busca.

Además, tenemos lo que llamamos memoria de orientación. Se trata de una guía de comportamiento para el agente, almacenada como un documento de Markdown que se carga en el contexto del agente al inicio de cada ejecución. Piensa en ella como un archivo AGENTS.md o como el modelo de amenazas que necesitaría un agente que analiza el código en busca de vulnerabilidades. Contiene reglas como "cuando veas alertas obsoletas de sincronización de Okta, comprueba los trabajos resource-sync y group-sync antes de concluir que se trata de un problema sistémico" o "el usuario X está realizando tareas de mantenimiento en el sistema Y esta semana; considera esas alertas como esperadas".

El agente puede actualizar su propia memoria de orientación cuando un ingeniero de seguridad lo corrige. Si alguien le dice: "eso lo manejaste mal; esto es lo que deberías hacer en su lugar", esa corrección se conserva para futuras ejecuciones. Sin embargo, aprendimos a ser cuidadosos con lo que se incorpora a la memoria de orientación y lo que permanece en la capa RAG. Una lección puntual sobre un tipo específico de alerta debería incorporarse al contexto de investigación para que aparezca como antecedente al analizar futuras alertas similares. Una regla de comportamiento que debería cambiar la forma en que el agente aborda todas las alertas pertenece a la memoria de orientación. Uno de nuestros primeros errores fue guardar todo en la memoria de orientación, lo que empezó a modificar el comportamiento del agente de maneras no deseadas. Los precedentes y las políticas son cosas distintas y deben mantenerse por separado.

También utilizamos registros respaldados por una base de datos en Tines para objetos con estado: solicitudes de incorporación de cambios abiertas creadas por el agente, el estado de las investigaciones en Panther y otros elementos que requieren claves estables y seguimiento de estado, en lugar de recuperación mediante lenguaje natural. Son componentes más sencillos, pero igualmente necesarios.

La capa de memoria más interesante es la memoria procedimental, y resuelve directamente el problema del descubrimiento de esquemas que describimos antes. Le dimos al subagente de investigación su propio almacén de memoria, organizado mediante etiquetas(aws,okta, osquery, workshop, etc.). Antes de iniciar una consulta, el agente carga las memorias relevantes para las fuentes de datos que está a punto de consultar. Después de completar una investigación que requirió descubrir el esquema, guarda lo que aprendió:

Title: Job Description Fields in Workiva Logs (2026-03-12T16:25:21 UTC)
Memory: Job descriptions for each user within the system can be found within the field 'jd' in the table 'WORKIVA_USERS'.

Un segundo LLM (que utiliza un modelo más ligero) se encarga de dar formato a la memoria: toma el hallazgo sin procesar, genera un título con una marca de tiempo en UTC, le asigna etiquetas y escribe la memoria. La primera vez que le preguntamos al agente de investigación sobre la actividad en Zoom, fueron necesarias varias consultas exploratorias. Después de guardar una memoria, la misma pregunta requirió una sola consulta. Ese patrón se repitió en distintas fuentes de datos a medida que el agente iba desarrollando su propio manual de operaciones mediante prueba y error.

Ejemplos de investigaciones realizadas por el agente

Para ilustrar cómo funciona el agente en la práctica, aquí presentamos tres ejemplos recientes.

El primero corresponde a una alerta que se activó porque alguien instaló una app de transcripción de audio para macOS que no había sido revisada ni aprobada para su uso en Figma. El agente de triaje leyó el hilo de la alerta, recuperó alertas históricas similares de la capa RAG y, después, utilizó sus herramientas de Okta y Workshop para unir las piezas: el actor era el mismo ingeniero que había creado la regla de detección: ¡yo, Matthew! Workshop mostró una regla creada ese mismo día, con alcance individual, para realizar pruebas. Conclusión: el autor de la regla estaba probando su propia detección. No era necesario tomar ninguna medida. El agente incluso dejó una nota indicando que, según mi estado en Slack, estaba completamente concentrado en mi trabajo y que quizá tardaría un poco en confirmar mis actividades.

Otro caso: se seguían activando alertas de Snowflake para la misma cuenta de servicio. El agente describió el estado actual, delegó al subagente de investigación la consulta de los registros de auditoría correspondientes, identificó la causa de la recurrencia de las alertas, encontró que ya existía una solicitud de incorporación de cambios en borrador para suprimirlas y explicó la solución a largo plazo que se estaba analizando en otro hilo. Así, el ingeniero de guardia obtuvo un panorama completo sin necesidad de abrir una sola pestaña, algo que habría sido impensable apenas unos meses antes.

Por último, solemos generar alertas por situaciones que podrían estar relacionadas con malware, pero que, en la mayoría de los casos, corresponden a comportamientos completamente legítimos (por ejemplo, la instalación de un servicio de inicio desconocido en las MacBooks de Figma). Antes, esto habría sido impensable: nuestro equipo brinda soporte a miles de Figmates y el volumen de alertas nos habría desbordado rápidamente. Sin embargo, con este nuevo modelo, nuestro agente puede verificar que el binario esté firmado por una entidad de confianza, utilizar la capacidad de consulta de Panther para determinar cómo se instaló (mediante Homebrew, la App Store, etc.) y redactar automáticamente los cambios de código necesarios para que, en el futuro, la alerta se suprima cuando se presenten condiciones que ya se consideran seguras, todo ello sin intervención humana.

De la investigación a los cambios en el código

Lo que más nos sorprendió, por el tiempo que ahorra, es el momento en que el agente pasa de decir: “Ya entendí qué está ocurriendo” a “Aquí está la solicitud de incorporación de cambios que lo corrige”.

Hay dos rutas en el código. Para los cambios en las reglas de detección, las listas de permitidos y la supresión de alertas, el agente abre solicitudes de incorporación de cambios en nuestro repositorio de detecciones de Panther. Este es el caso más común: una alerta sigue activándose por un patrón que ya se sabe que es benigno, un ingeniero de guardia confirma en el hilo de Slack que se trata de un falso positivo y el agente genera una entrada en la lista de permitidos o ajusta la regla de detección. Para todo lo demás, como cambios en la infraestructura, configuraciones de servicios, Terraform o la configuración de RBAC y proveedor de identidad, el agente trabaja sobre nuestro monorepositorio.

Si un revisor deja comentarios en la solicitud de incorporación de cambios, el agente los recibe mediante un webhook de GitHub y puede realizar cambios adicionales o responder. También puede hacer un rebase de las ramas desactualizadas sobre la rama master más reciente cuando las solicitudes de incorporación de cambios permanecen abiertas durante un tiempo.

Mecanismos de protección

Todas las llamadas de herramientas incluyen salvaguardas deterministas para asegurar que el agente no intente hacer algo que no queremos que haga. Por ejemplo, cada solicitud de incorporación de cambios que crea el agente se establece automáticamente como borrador. Esto se realiza como un paso posterior determinista en el flujo de trabajo de Tines, no como una indicación, porque desde el principio descubrimos que confiar en que el LLM recordara "crear siempre como borrador" no era lo suficientemente fiable.

Utilizamos este tipo de contrato para las llamadas a herramientas con el fin de aplicar de forma determinista toda clase de controles, desde garantizar que el agente no reciba ni procese información confidencial de los empleados al recuperar datos de Okta, hasta asegurar que no intente cerrar ni modificar solicitudes de incorporación de cambios que no haya creado. Como la seguridad de cualquier sistema depende de contar con controles en capas, también nos aseguramos de que las herramientas disponibles para el agente tengan un alcance bien definido, cuenten con la autorización correspondiente y estén sujetas a monitoreo, además de que el propio agente actúe en nombre de un miembro autorizado del equipo.

También hemos procurado limitar las consecuencias de un contexto incorrecto. El agente no tiene acceso permanente a canales completos de Slack y, fuera de los mensajes directos, solo puede leer un hilo cuando se le vuelve a etiquetar explícitamente en el mensaje más reciente.

Por último, nos sentimos mucho más cómodos con la autonomía cuando la acción es limitada, reversible y está respaldada por evidencia clara que cuando es amplia, destructiva o difícil de auditar. En la práctica, esto significa que la investigación basada principalmente en lectura, la detección de duplicados, la recuperación de precedentes y la remediación en borrador se adaptan mejor a la ejecución agéntica que las rutas de escritura genéricas de amplio alcance.

Esperamos que, con el tiempo, una mayor proporción de las alertas se gestione automáticamente, pero solo con controles más estrictos: ámbitos de acción más limitados, mejores evaluaciones (como este ejemplo de cómo generar confianza en los agentes de IA mediante métricas) y una procedencia más clara que explique por qué el sistema llegó a una conclusión.

En retrospectiva

Si tuviéramos que empezar de cero, estas son algunas cosas que haríamos de otra manera:

• La memoria procedimental debió haber estado presente desde el principio. La memoria del esquema creada por el propio agente de investigación se incorporó en una etapa avanzada y la mejora fue tan significativa que, en retrospectiva, todo el trabajo realizado antes de eso casi parece haber sido en vano.
• La configuración como código es esencial para evitar que la capa de agentes se fragmente. Como los miembros del equipo quieren iterar con rapidez, es común que terminen creando y utilizando copias ligeramente distintas del mismo agente principal, cada una con configuraciones de herramientas ligeramente diferentes y destinadas a distintos propósitos. Como es de esperarse, esto dificulta mucho garantizar que todas las herramientas disponibles para esos agentes sean consistentes y funcionen de la misma manera. Hoy en día, nuestro conjunto principal de herramientas se configura y administra fuera de cualquier agente individual, mediante configuración como código, lo que garantiza que todos los agentes puedan beneficiarse de un conjunto de acciones estandarizado y bien mantenido.
• Si estás desarrollando un agente para integrarlo con Slack, conviene definir desde el principio el modelo de confianza para los canales públicos. Nuestros agentes cuentan con controles de autorización para garantizar que solo los miembros del equipo de seguridad puedan utilizarlos, pero si un agente decide revisar registros detallados de la actividad de un usuario, podría sacar a la luz todo tipo de información confidencial. Los datos sobre la actividad de un usuario durante ese día son perfectamente adecuados en un hilo privado del equipo de seguridad, pero se convierten en un problema importante en un canal con un centenar de personas. Nosotros resolvemos esto mediante el diseño de indicaciones adaptados al contexto del canal y otros controles deterministas, pero es el tipo de aspecto que conviene diseñar desde el principio, en lugar de incorporarlo después.

Dónde estamos hoy y qué viene después

El sistema se encarga de todo el trabajo inicial de respuesta a incidentes de seguridad del equipo. El trabajo del ingeniero de guardia pasó de "investigar desde cero" a "revisar lo que encontró el agente, confirmarlo o corregirlo, y encargarse de los casos que requieren criterio humano".

Hemos observado una reducción de alrededor del 70 % en el tiempo de resolución de alertas complejas, una disminución del 20 % en los avisos al personal de guardia gracias a la reducción del nivel de gravedad impulsada por IA, un 25 % menos de solicitudes de aprobación de software para dispositivos terminales (el agente detecta cuándo un usuario está preguntando por una herramienta y lo dirige a alternativas aprobadas comparables) y un aumento significativo en la confianza de los ingenieros de guardia en la calidad de las resoluciones, ya que la cadena de evidencia del agente es explícita y puede revisarse.

Dentro de un año, el sistema habrá incorporado miles de decisiones de triaje inicial, mapeos de esquemas y correcciones de comportamiento que ninguna persona del equipo podría retener por sí sola. Eso es lo que más nos entusiasma: no una ejecución aislada del agente, sino el hecho de que cada ejecución hace que la siguiente sea más económica y precisa.

Gran parte de la siguiente etapa consiste en construir un mejor plano de control alrededor del modelo. Queremos establecer distinciones más claras entre nuestras capas de memoria para los precedentes, las políticas y el estado. Queremos contar con mejores mecanismos para decidir cuándo una alerta puede cerrarse automáticamente de forma segura y cuándo debe escalarse, incluso si el modelo parece estar seguro. También queremos que los flujos de trabajo en los que más confiamos dejen de depender del comportamiento definido mediante indicaciones y pasen a una automatización determinista e inspeccionable.

Una última reflexión: se habla mucho de si vale la pena utilizar IA para investigar problemas, porque la IA no es perfecta. Pero los humanos tampoco son perfectos. Creemos que no es una elección entre humanos o IA. Más bien, hay muchas cosas que se pueden hacer entre estos dos extremos para reducir los riesgos y mejorar la eficiencia, y todavía estamos definiendo cómo hacerlo.

Nos entusiasma y nos enorgullece lo que hemos construido, pero sabemos que esto es apenas el comienzo de un camino más largo, con un enorme potencial y posibles obstáculos. Si otros equipos están construyendo sistemas similares, ¡no duden en ponerse en contacto con nosotros! Nos encantaría intercambiar ideas.