Ilia Razvin, fundador y CEO de IOSYA: «El futuro no es un ayer mejorado».

Para Ilia Razvin, los problemas de los agentes de IA se entienden mejor desde la perspectiva de la ingeniería. El fundador y CEO de IOSYA comenzó su carrera trabajando con sensores electroquímicos y modelos de procesos en entornos químicos, donde una suposición errónea podía tener consecuencias físicas. Esa experiencia dio forma a un principio sencillo: un resultado sin las condiciones en las que se obtuvo no es un resultado. Ahora aplica este principio a la IA y sostiene que un agente que produce una respuesta convincente tiene un valor limitado si no puede mostrar qué fuente ha utilizado, en qué versión se ha basado, qué decisiones ha tomado durante el proceso o cuándo debe detenerse.

En esta entrevista, Razvin explica por qué tantos agentes de IA «superan la demo y mueren en la segunda semana», y por qué gran parte del trabajo difícil para hacerlos fiables se desarrolla fuera del propio modelo. Habla de cómo IOSYA gestiona documentación técnica desordenada, por qué los modelos más pequeños pueden superar a los sistemas más avanzados en tareas rutinarias de producción, la realidad práctica de la inyección de prompts y el envenenamiento de los sistemas de recuperación, y en qué ámbitos la supervisión humana sigue siendo esencial. Su argumento no gira tanto en torno a hacer que la IA parezca más autónoma como a construir sistemas trazables y verificables, capaces de admitir cuándo no saben algo.

Has dicho que muchos agentes de IA «superan la demo y mueren en la segunda semana». ¿Qué suele salir mal cuando un agente se expone a un entorno empresarial real y qué diferencia a un agente que sobrevive de uno que no lo consigue?

Una demo funciona con una selección cuidadosamente preparada. Tres documentos limpios, un único recorrido sin obstáculos y una persona en la sala que ya sabe cómo es la respuesta correcta. Todo lo que hay en esa sala contribuye discretamente a que la máquina parezca competente.

En la segunda semana, el agente se enfrenta al repositorio real. Cuatro versiones de la misma especificación, una de ellas un escaneo de una copia impresa de una revisión. Un archivo llamado FINAL_v2_usa_este. Un buzón compartido en el que se tomó la decisión real en una respuesta que nadie archivó. La persona que sabía qué documento prevalece está de vacaciones. Nada de esto es hostil. Es simplemente lo normal, y lo normal es el caso difícil.

Entonces falla de cuatro maneras, en este orden.

Recuerda la conversación, pero no el trabajo. La sesión se cierra y todo lo que la empresa aprendió durante ella desaparece. La semana siguiente, alguien hace la misma pregunta y vuelve a pagar por la misma respuesta.

No puede mostrar su razonamiento. Puede que tenga razón, pero no hay ninguna fuente, ninguna versión ni ningún rastro del documento que ha leído y del que ha ignorado, así que nadie está dispuesto a firmar el resultado. Una respuesta que nadie puede firmar no es una respuesta. Es una opinión por la que se paga una suscripción.

No tiene ningún plan para gestionar sus propios fallos. No se detiene cuando debería. Adivina con fluidez, y esa fluidez es precisamente lo que hace peligrosa la suposición. En una demo, eso parece confianza. En producción, se convierte en un incidente con fecha.

Y nadie se hace responsable. En la demo había una persona responsable a su lado. En la segunda semana, esa persona volvió a su trabajo de verdad.

Lo que sobrevive es poco vistoso y estructural. No un asistente general conectado a una empresa, sino un proceso definido: qué lo inicia, a qué datos puede acceder, qué acciones puede realizar, dónde interviene una persona para dar su aprobación, qué produce y qué hace cuando no puede determinar algo. Además, un registro completo de ejecución, almacenado fuera del modelo, para poder reconstruir seis semanas después por qué hizo lo que hizo. En eso se basa lo que construimos en IOSYA, y no es precisamente la parte que queda bien en las fotos.

Mi formación es en química. En la planta de una fábrica, la última cifra no explica nada si alguien ha sustituido un sensor antes de obtenerla. La demo comprueba si el modelo es inteligente. La segunda semana comprueba si tu empresa ha dejado constancia de algo por escrito.

Los entornos industriales incluyen cientos de páginas de especificaciones técnicas, planos CAD y tablas. ¿Cómo estáis resolviendo el problema de conseguir que los agentes comprendan de forma fiable este tipo de datos técnicos desordenados y altamente estructurados?

No pidiéndoselo al modelo.

La reacción habitual es entregarle un PDF de 300 páginas y cruzar los dedos. Eso falla por un motivo que no tiene nada que ver con la calidad del modelo: un documento no es un corpus, sino una prueba documental. Las pruebas llevan asociadas unas condiciones, y convertirlas indiscriminadamente en texto destruye precisamente la parte que las hace útiles.

Por eso, el trabajo se realiza antes de involucrar al modelo.

Procesamos los documentos para conservar su estructura, no para convertirlos en prosa. Una tabla sigue siendo una tabla. Una celda combinada contiene información: normalmente significa «esto se aplica a las tres filas siguientes». Si se aplana la tabla y se elimina esa estructura, se está inventando un dato. Lo mismo ocurre con las unidades, las tolerancias, las notas al pie y el pequeño asterisco que indica «excepto para la variante B».

Cada fragmento conserva su referencia exacta: identificador del documento, revisión, fecha de publicación, página, tabla y cláusula. Para nosotros, un fragmento que ha perdido su referencia carece de valor, por muy relevante que parezca. Una medición sin las condiciones en las que se obtuvo no es un resultado. Una línea de una especificación sin su número de revisión no es una especificación.

Gestionamos los planos con honestidad. No fingimos que un modelo interprete la geometría como lo hace un ingeniero. Extraemos aquello que realmente puede leer una máquina (el cajetín, el índice de revisiones, la lista de piezas, las anotaciones y las indicaciones de cotas cuando existen) y tratamos la geometría propiamente dicha como algo que debe inspeccionar una persona. Cualquier otra cosa es un truco para una demo, y así es como se obtiene una respuesta segura de sí misma sobre una pieza que se rediseñó hace tres años.

La primera pregunta siempre es qué documento prevalece. Este es el paso que la gente se salta y el que causa la mayor parte de los problemas. Si hay cuatro copias de una especificación, la primera tarea del sistema no consiste en responder a tu pregunta. Consiste en determinar cuál está vigente, señalar las contradicciones entre ellas y negarse a continuar cuando no puede establecerlo. La aviación y el derecho gestionan correctamente las versiones de sus documentos porque un documento sin historial carece de valor probatorio.

Y el rechazo es una función que incorporamos deliberadamente. «No dispongo de la revisión vigente que rige esta sección» es una respuesta correcta. También es una respuesta que nunca aparece en una demo.

El resultado es poco llamativo, y ese es precisamente el objetivo. El modelo realiza el pequeño paso final. La fiabilidad reside en la capa subyacente, donde las fuentes, las versiones y las decisiones se conservan en un formato que pertenece a la empresa, en lugar de tener que alquilarlo.

Existe una tendencia a dar por hecho que el modelo de frontera más potente es automáticamente la mejor opción. ¿En qué casos has comprobado que un modelo más pequeño o barato ofrece mejores resultados, y cuándo empiezan a ser más importantes el coste y la latencia que la capacidad bruta?

Es una pregunta muy compleja, y el sector la responde mal porque el modelo de frontera es el que queda mejor en las fotos.

Hay que empezar por la tarea. Un modelo de frontera está pensado para emitir juicios en situaciones ambiguas: la pregunta está insuficientemente definida, una persona leerá la respuesta y actuará en consecuencia, equivocarse resulta caro y acertar exige ponderar factores que nadie ha llegado a documentar.

La mayor parte del trabajo en producción no es así. La mayor parte es rutinaria. Extraer once campos de una factura. Clasificar un documento entrante. Decidir cuál de seis rutas debe seguir una incidencia. Comprobar un valor con respecto a una regla. Estas tareas tienen respuestas correctas.

La extracción conforme a un esquema fijo es el primer ámbito en el que gana el modelo pequeño. No estás pidiendo inteligencia, sino disciplina. Un modelo pequeño con un esquema estricto y un validador produce menos variabilidad que un modelo grande que improvisa, y la variabilidad es lo que mantiene a la gente despierta por la noche.

Lo mismo ocurre con la clasificación y el enrutamiento, una vez que se dispone de un conjunto de evaluación. Se crean las pruebas de evaluación, se miden ambos modelos y la discusión termina. Nadie discute una cifra.

Después está la latencia, cuyos efectos se acumulan de una forma que nadie modeliza de antemano. Una persona espera ocho segundos una vez y lo acepta. Encadena catorce pasos y ya son dos minutos; cuando se llega a los dos minutos, la persona cierra la pestaña y lo hace a mano. El proyecto está muerto y nadie ha llegado a registrar un error.

El punto de inflexión es preciso: cuando la tarea tiene una respuesta correcta verificable y las evaluaciones demuestran que el modelo pequeño puede alcanzarla. Superado ese umbral, una mayor capacidad no aporta nada y se paga por ella en cada llamada, para siempre. Reserva el modelo caro para los pasos irreversibles, ambiguos, que se ejecutan una sola vez o cuyas respuestas leerá una persona que actuará en consecuencia.

Hay una dificultad, y es precisamente por lo que me importa tanto esta cuestión. Distribuir los distintos pasos entre diferentes modelos solo funciona si el estado se conserva fuera de ellos. La memoria, las fuentes, las decisiones y el registro de ejecución. Si todo eso permanece dentro del objeto de sesión de un único proveedor, no puedes cambiar ni un solo paso sin perder el hilo. El modelo es potente, pero sustituible; y eso solo es cierto si lo has diseñado para que lo sea.

La inyección de prompts y el envenenamiento de RAG suelen tratarse como riesgos teóricos, pero tú te has enfrentado a ellos en sistemas reales. ¿Cómo eran esos ataques o fallos en la práctica y qué cambiasteis?

Lo primero que hay que decir es que casi nunca parecen un ataque. Esa expectativa es el problema. La gente se imagina a un hacker. Lo que encuentras es papelería.

Instrucciones dentro de un documento que debías leer: un PDF de un proveedor, una plantilla, el pie de un correo electrónico, un comentario en una celda de una hoja de cálculo o texto de un color que ningún sistema muestra. Texto escrito para una persona, o quizá sin ningún propósito en particular, que el sistema obedece porque no dispone de ningún mecanismo estructural para distinguir entre «contenido que me han pedido leer» e «instrucción que me han dado».

Después está el envenenamiento de la recuperación de información que nadie ha provocado deliberadamente. Una revisión obsoleta sigue en la carpeta, indexada con exactamente el mismo nivel de confianza que la vigente. En esta historia no hay ningún atacante. Sin embargo, el efecto sobre el resultado es idéntico. Esta es la variante que realmente cuesta dinero a las empresas y de la que nadie da charlas en conferencias.

Y están los duplicados que acaban imponiéndose a la verdad. La misma cifra incorrecta aparece en seis sitios porque seis personas han copiado una diapositiva. La cifra correcta aparece una sola vez, en la fuente original. Si no diseñas el sistema para evitarlo, la recuperación de información se convierte en un concurso de popularidad.

Lo que cambiamos en IOSYA es estructural, no cosmético.

El contenido recuperado son datos y nunca puede convertirse en una instrucción. No se trata de pedir amablemente al modelo que lo ignore, sino de separar ambas cosas a nivel de arquitectura, de modo que las instrucciones lleguen por un canal y el material por otro.

Los permisos están vinculados al operador, no al prompt. Una instrucción inyectada puede solicitar lo que quiera. Si «enviar un correo electrónico externo» no forma parte de las herramientas disponibles para ese operador, la solicitud no tiene adónde ir. No puedes conseguir mediante persuasión una capacidad que nunca se ha concedido.

Cada fragmento recuperado incluye información sobre su procedencia, y los orígenes no fiables se marcan como tales, porque un documento externo es una prueba procedente de una fuente no verificada. Eso es exactamente lo que es.

Las acciones de escritura tienen puntos de control. Las acciones irreversibles requieren la intervención de una persona. Leer tiene un coste bajo si te equivocas. Enviar, no.

Y existe un registro completo de ejecución: qué documento, qué versión, qué herramienta y qué decisión, y en qué orden. La mayoría de los equipos no pueden responder a la pregunta «¿por qué hizo eso?» cuando se refiere al martes pasado. Hasta que puedas responderla, no tienes una estrategia de seguridad. Tienes un estado de ánimo.

Nada de esto es exótico. Es la disciplina que aplica un laboratorio regulado a la manipulación de muestras, trasladada a otro edificio.

Cuando una respuesta incorrecta puede tener consecuencias físicas o financieras, ¿cómo decidís qué puede hacer el agente de forma autónoma y en qué momentos debe intervenir una persona?

No establecemos un nivel de autonomía. Lo definimos para cada acción y lo determinamos a partir de cuatro preguntas.

¿Se puede deshacer, cuánto se tarda y quién asume el coste de hacerlo? Un borrador se puede revertir en segundos. Un correo electrónico enviado a un cliente puede requerir una semana para reparar la relación. Una orden de pago no se puede revertir en absoluto. Son tres regímenes diferentes, y tratarlos como si fueran una única configuración es la forma en que se producen los accidentes.

¿Hasta dónde llega su alcance? ¿A un documento, a un departamento, a un proveedor o a todo el mundo?

¿Puede una máquina comprobar que es correcto? Si un validador, una regla o una prueba puede confirmar el resultado, la autonomía está justificada. Si la corrección requiere a una persona que conozca la planta, no lo está.

¿Habrá alguien dispuesto a poner su nombre en el resultado? Si la respuesta sale de la empresa o entra en un registro oficial, una persona debe aprobarla. No porque no se pueda confiar en la máquina, sino porque la responsabilidad debe recaer en una persona y ninguna arquitectura ha resuelto jamás ese problema.

En la práctica, la lectura, la comparación, la extracción, la redacción de borradores y la detección de contradicciones pueden realizarse de forma autónoma. Cualquier acción que mueva dinero, modifique un sistema de registro, salga de la organización o indique a una persona que realice una acción física requiere un punto de control.

Después viene la parte que la gente hace mal incluso cuando ha hecho bien todo lo demás. El punto de control tiene que ser sencillo y rápido. Si aprobar requiere veinte segundos y muestra cinco cosas (qué está a punto de hacer el sistema, por qué, qué fuentes utiliza, qué cambios se producirán y cómo deshacerlos), la gente lo lee. Si muestra un bloque interminable de texto, en una semana estarán aprobando a ciegas y habrás construido un sello de goma con un registro de auditoría. Eso es peor que no tener ningún punto de control, porque ahora dispones de documentación que demuestra que una persona dio su aprobación.

Y las condiciones de parada se establecen por escrito antes de ejecutar nada. Qué ocurre cuando faltan datos. Cuando dos fuentes discrepan. Cuando la confianza es baja. Cuántos intentos se permiten, qué sucede después y a quién se informa. Un sistema que no está diseñado para fallar fallará de todos modos, pero lo hará sin avisar a nadie.

Has comparado la programación con agentes con trabajar con «un ingeniero sénior con demencia». ¿Qué revela esa analogía y qué tendría que cambiar para que confiaras en un agente para realizar de principio a fin tareas de ingeniería realmente críticas?

Revela que la capacidad y la continuidad son dos cosas distintas, y que hemos estado comprando una mientras dábamos por hecho que la otra venía incluida.

La parte del ingeniero sénior es real. Por unidad de trabajo, es realmente bueno. Lee código desconocido con rapidez, conoce patrones y, a menudo, trabaja más rápido que yo. Lo utilizo a diario y no estoy fingiendo escepticismo.

La otra parte también es real. Vuelve a deducir una decisión que ya habías tomado y llega a la conclusión contraria. Reintroduce con total confianza el error que eliminaste el martes, porque el motivo por el que lo eliminaste se comentó en una reunión y no consta en ningún archivo al que pueda acceder. Contradice lo que hizo ayer sin darse cuenta de que ayer ocurrió. Así que acabas haciendo un trabajo que no existía hace tres años: tú eres quien mantiene la continuidad. Tú mantienes el hilo, y el hilo es la parte costosa.

La analogía es injusta en un sentido, y debo decirlo. Una persona con esa enfermedad sabe que algo va mal. La máquina no. No tiene ninguna señal que le indique dónde terminan sus propios conocimientos, por lo que su modo de fallo consiste en continuar con confianza en lugar de detenerse. En el software de producción, continuar con confianza es la característica que más cuesta.

Antes de confiarle de principio a fin cualquier tarea crítica, hacen falta cinco cosas.

Memoria del trabajo, estructurada y fuera del modelo. Las decisiones y sus motivos, las opciones descartadas y por qué, y las versiones de las fuentes. No el historial del chat. El historial del chat es la transcripción de una conversación; lo que necesitas es el estado de un proyecto. Esa distinción explica, más o menos, por qué existe IOSYA.

Incertidumbre calibrada con una parada real: la capacidad de decir «no puedo determinarlo» y detenerse, en lugar de producir algo que tenga la forma de una respuesta.

Verificación realizada por la máquina, no por una persona. Así es como siempre ha funcionado la ingeniería crítica. No confiamos en un puente porque el ingeniero fuera inteligente. Confiamos en él porque se ha comprobado mediante procedimientos, conforme a normas y por personas que no lo diseñaron.

Un registro que pueda auditar después. No por desconfianza. Es el estándar habitual para cualquier ingeniero humano que trabaje en algo importante, y no hay ningún argumento que justifique aplicar uno inferior en este caso.

Y un nombre al final. Alguien que asuma la responsabilidad. Ninguna nueva versión de un modelo resolverá eso, y no creo que deba hacerlo.

Con esas cinco cosas, «de principio a fin» deja de ser una expresión aterradora, porque significará más o menos lo mismo que en la aviación: automatizado, supervisado, trazable y con capacidad de detenerse.

Todavía no hemos llegado a ese punto. Estamos en un lugar útil, que es algo distinto. El futuro no es un ayer mejorado.