Plurai capta 13 millones de dólares para un simulador que detecta errores de agentes de IA

Un agente sabe reservar viajes de trabajo hasta que un empleado le pide que haga una excepción y compre un billete que supera el límite establecido. En la demostración, todo parecía convincente; en el sistema de producción, se produjo un gasto innecesario. La startup Plurai propone reproducir estas situaciones de antemano en un simulador de sistemas empresariales. Para los desarrolladores, la cuestión práctica es cómo comprobar el comportamiento del agente antes de darle acceso a operaciones reales.

Según TechCrunch, la compañía ha captado 13 millones de dólares en una ronda de financiación semilla. Team8 lideró la ronda, en la que también participaron U&I, Velocity y Mercer. Los fundadores, Ilan Kadar y Elad Levy, trabajaron anteriormente en Nexar, y Kadar se dedicó a la simulación y la evaluación de software para conducción autónoma junto con Waymo. Ahora, el equipo traslada esa experiencia a los agentes de software.

Cómo funciona el entorno de pruebas

Plurai crea una réplica digital del entorno en el que operará el agente: las bases de conocimiento y las herramientas a su disposición. Después, la plataforma construye un grafo de acciones posibles y lo utiliza para preparar pruebas de escenarios complejos. Según la descripción de la compañía, esto ayuda a detectar y corregir errores antes del lanzamiento.

Tomemos el mismo asistente de viajes de trabajo. Una prueba convencional mostrará si puede encontrar un vuelo y completar una reserva. En una simulación se puede comprobar una secuencia más complicada: el billete adecuado supera el presupuesto, el usuario insiste en comprarlo y la regla sobre excepciones está en un documento aparte. En este caso, el éxito consiste en gestionar correctamente la restricción, no simplemente en completar la reserva. Es una ilustración del enfoque, no un resultado publicado de las pruebas de Plurai.

Al trabajar con datos surge un problema similar. Responder a una pregunta a partir de una sola base de datos es más sencillo que contrastar información de varios sistemas y elegir la acción correcta. Una conversación larga con un cliente añade otra carga: el agente debe mantener presentes las condiciones de la tarea a medida que se acumula el contexto.

Por qué las empresas pueden necesitar modelos pequeños

Las pruebas son la primera parte del plan. La segunda consiste en utilizar los datos sintéticos obtenidos para ajustar modelos pequeños de pesos abiertos a las tareas de un cliente concreto. Según TechCrunch, la plataforma funciona junto a herramientas existentes, como Claude Code, Codex, Copilot y Cursor.

La lógica es clara: si un agente ejecuta un conjunto limitado de operaciones, a la empresa puede resultarle rentable entrenar un modelo específicamente para ellas. El simulador debe ayudar a dividir una tarea grande en otras más pequeñas y comprobar si se mantiene la calidad necesaria tras cambiar de modelo.

Kadar afirma que es posible reducir los costes entre 10 y 100 veces con una calidad comparable o superior a la de los modelos grandes. El artículo también menciona pruebas realizadas junto con Nvidia y Nebius en las que, según la compañía, los modelos de Plurai superaron a algunos modelos punteros de gama media con un coste menor.

Sin embargo, el texto proporcionado no incluye una metodología detallada, el conjunto de tareas, los nombres de los modelos comparados ni un cálculo completo del coste. Por tanto, estas cifras deben tratarse como afirmaciones del proveedor. Todavía no permiten estimar el ahorro para un producto ajeno.

Qué comprobar antes de la implantación

La principal limitación de este enfoque es la fidelidad con la que el simulador reproduce el entorno de producción. Si omite restricciones reales de acceso, documentos desactualizados o fallos de las herramientas, un buen resultado en las pruebas puede generar una falsa sensación de seguridad. También es difícil comprobar literalmente todas las acciones posibles de un agente en un sistema complejo; un grafo de escenarios no garantiza por sí solo una cobertura completa.

También está la cuestión económica. Una llamada al modelo más barata no implica necesariamente una tarea completada a menor coste. Hay que tener en cuenta los reintentos, la intervención de un empleado, el mantenimiento del simulador y la actualización del entrenamiento cuando cambian las reglas de la empresa.

Para un equipo que ya despliega agentes, un paso útil es recopilar sus propios casos de fallo y convertirlos en pruebas repetibles. Por ejemplo, medir por separado la finalización de la tarea, el cumplimiento de las políticas y la necesidad de correcciones manuales. Plurai propone combinar estas pruebas con la preparación de datos de entrenamiento. El interés está en la posibilidad de detectar de forma sistemática errores de un flujo de trabajo concreto; el ahorro prometido tendrá que demostrarse con las tareas de cada equipo.