AI en Israel

La israelí AIR se presenta con 50 millones para proteger agentes de IA

Dos rondas semilla cerradas en pocas semanas financian una plataforma que descubre agentes empresariales, revisa sus herramientas y puede bloquear componentes que no cumplen sus criterios.

Una puerta transparente separa un agente de IA abstracto de varios complementos
Ilustración conceptual: revisar componentes antes de permitir que un agente de IA los utilice.

AIR, una empresa israelí de seguridad para agentes de IA, se presentó públicamente con 50 millones de dólares obtenidos en dos rondas semilla cerradas con pocas semanas de diferencia. Según TechCrunch, que publicó la noticia el 1 de septiembre de 2026, Sequoia lideró la primera, de 10 millones, y Greenoaks la segunda, de 40 millones. Su foco es práctico: qué herramientas utilizan los agentes empresariales y quién las revisa durante el proceso.

Sus fundadores son Yair Saban, director ejecutivo, y Niv Hoffman, director de tecnología. Ambos proceden de la Unidad 8200 de Israel, donde trabajaron en ciberseguridad ofensiva. El producto busca agentes dentro de las empresas, revisa continuamente sus Skills, herramientas y componentes externos y puede impedir interacciones que no cumplan los criterios de seguridad. Es la descripción de una oferta, no una garantía contra cualquier error posible.

Dos rondas y dos inversores principales

La suma se compone de dos operaciones: 10 millones de dólares liderados por Sequoia y otros 40 millones por Greenoaks. Según TechCrunch, se cerraron en pocas semanas. Conviene conservar esa estructura y no presentar todo como una única operación. La cantidad tampoco determina la valoración de AIR ni las condiciones de cada fondo, datos que no se divulgaron con esas cifras.

Otros inversores citados son Swish y Netz, junto con particulares como Zach Frankel, presidente de Cognition; Yinon Costica, cofundador de Wiz; Ofir Ehrlich, cofundador de Eon; Anne Neuberger; Omer Adam; y Varun Anand, cofundador de Clay. La lista identifica participantes en la financiación. No demuestra el rendimiento de la plataforma ni significa que las empresas vinculadas a ellos sean clientes de AIR.

El vínculo israelí es claro por la identidad y trayectoria de los fundadores. Para entender el producto, sin embargo, hay que pasar de la financiación al punto de control que pretende crear. No basta con preguntar quién construyó el agente o qué modelo lo mueve. También importan los componentes que carga, las fuentes que consulta y cómo decide la organización con qué puede interactuar.

Primero, saber qué agentes están funcionando

La primera etapa descrita es el descubrimiento de agentes activos dentro de la organización. Sirve de base para seguir las herramientas que utilizan. Antes de aplicar una política a un componente, una empresa necesita saber dónde se usa y qué agentes dependen de él. El inventario y la revisión son, por tanto, partes relacionadas de una misma visión del uso.

Sobre ese inventario se sitúa la evaluación continua de Skills, herramientas y componentes externos. En términos prácticos, una Skill añade instrucciones o capacidades al flujo de un agente. El nombre no constituye una aprobación de seguridad. Aunque encaje en una tarea, sigue siendo necesario saber si cumple la política prevista. AIR presenta la revisión permanente del entorno del agente como una parte central de su producto.

De ahí la diferencia entre saber que un componente existe y decidir que puede utilizarse. Un inventario aporta visibilidad, pero no determina por sí solo si una acción debe ejecutarse. La propuesta de AIR conecta esa visibilidad con una capa de aplicación de controles. La organización puede detectar la dependencia de un componente y exigir condiciones antes de permitir la interacción.

Controles en el momento de actuar

Según TechCrunch, la capa de AIR puede interceptar acciones como cargar una Skill u obtener contenido de internet. Contrasta las acciones y los componentes pertinentes con una lista de elementos autorizados que mantiene, y puede bloquear lo que no cumpla sus criterios. El énfasis está en revisar durante el trabajo, no solo en mostrar un inventario cuando la tarea ya terminó.

Una lista de autorizaciones delimita qué componentes cumplen las condiciones y cuáles no están permitidos. Pero la palabra "aprobado" no explica qué se examinó. Una organización debería preguntar por los criterios, la reevaluación y lo que ocurre ante un bloqueo. Son preguntas de un posible cliente, no afirmaciones de que el producto ya ofrezca una respuesta concreta a cada una.

Bloquear tampoco garantiza el éxito completo de una tarea. Un agente puede utilizar solo componentes autorizados y producir una respuesta que necesite revisión profesional. A la inversa, un bloqueo puede detener un proceso que una persona debe decidir cómo continuar. La seguridad de componentes e interacciones y la corrección del resultado empresarial son capas diferentes; una no elimina la otra.

Un catálogo de complementos revisados y sus límites

AIR también mantiene un mercado de complementos revisados. La idea complementa los controles: además de detener elementos que no cumplen las condiciones, ofrece un lugar donde encontrar componentes evaluados. Aun así, revisar un complemento no equivale a confirmar su adecuación a una tarea. No necesita necesariamente todos los permisos que solicita en cualquier uso posible; la organización debe definir sus límites.

Para responsables y equipos técnicos, la financiación señala una categoría concreta: proteger las herramientas y fuentes con las que interactúan los agentes. Conviene evaluar el sistema con un escenario definido, como cargar un componente o acceder a contenido, y determinar qué ve, qué comprueba y cómo bloquea. Es una base más práctica que la cantidad recaudada por sí sola.

Las dos rondas aportan 50 millones de dólares a AIR, pero la pregunta del producto es más tangible: antes de que un agente use otra herramienta, ¿alguien la ha revisado y puede la empresa detener su uso? Ahí se encuentran unos agentes con más capacidad de actuar y un negocio que necesita mantener el control. La propuesta está en supervisar continuamente ese encuentro, no en añadir otro componente de IA sin más. Al evaluar un proveedor, pedid distinguir entre un componente que el sistema desconoce y otro que ha revisado y bloqueado. La información disponible es diferente en cada caso, y la explicación debería permitir al responsable entender qué queda por aclarar antes de continuar.