Val Bercovici, Director de IA en WEKA – Serie de entrevistas

Val Bercovici, Director de IA en WEKA, es un ejecutivo de IA e infraestructura de datos enfocado en impulsar las tecnologías que sustentan la inteligencia artificial de próxima generación. Desde que se incorporó a WEKA como Director de IA en enero de 2025, se ha concentrado en construir infraestructura para agentes de IA, acelerar cargas de entrenamiento e inferencia, y mejorar la economía del cómputo de IA. Además de su cargo en WEKA, Bercovici actúa como asesor de IA para Home Dock, asesor estratégico para FermiHDI y The Hive, y presidente de PencilDATA, donde su trabajo abarca IA, ciberseguridad, blockchain, computación en la nube e infraestructura de datos. Su trayectoria refleja un enfoque de larga data en desarrollar y asesorar tecnologías emergentes diseñadas para soportar sistemas de IA cada vez más intensivos en datos.

WEKA es una empresa de infraestructura de datos nativa de IA que construye una plataforma definida por software diseñada para los exigentes requisitos de datos de la inteligencia artificial, aprendizaje automático, computación de alto rendimiento y otras cargas de trabajo aceleradas. La Plataforma de Datos WEKA brinda a las organizaciones una arquitectura unificada que puede operar en entornos locales, en la nube, híbridos y de borde, ayudando a eliminar cuellos de botella de almacenamiento, mejorar la utilización de GPU y acelerar el entrenamiento e inferencia de modelos de IA. La compañía posiciona cada vez más su tecnología alrededor de la emergente economía de inferencia y la IA agente, con una infraestructura diseñada para proporcionar acceso de alto rendimiento y baja latencia a datos a gran escala mientras simplifica pipelines de datos de IA complejos. WEKA atiende a empresas, proveedores de nube, organizaciones de investigación y desarrolladores de IA que operan algunos de los entornos informáticos más intensivos en rendimiento del mundo.

Su carrera lo ha llevado desde dar forma a la estrategia temprana de nube de NetApp y servir en la junta fundadora de Kubernetes hasta construir infraestructura de IA en WEKA. ¿Cómo ha influido esa evolución en su forma de pensar sobre la preparación de la infraestructura para la próxima fase de la IA?

Cada era de mi carrera se ha definido por el mismo patrón: el cuello de botella se desplaza y la industria tarda años en percatarse. En los primeros días de la nube y Kubernetes, vimos que la computación se volvió elástica y la orquestación se convirtió en el nuevo punto de estrangulamiento. Al salir de NetApp, donde fui CTO después de la adquisición de SolidFire, pensé que sabía cómo se veía la velocidad: milisegundos bajos para una lectura aleatoria de primer byte bajo cargas de trabajo de producción.

La razón por la que me uní a WEKA es genuinamente geek. Fue una estadística: la primera lectura aleatoria sin caché de un byte es de 70 microsegundos, lo cual no es un número de clase de almacenamiento. Nunca había considerado una latencia a nivel de microsegundo en este tipo de sistema. Eso fue la revelación: esta tecnología podría servir a aplicaciones de memoria, aplicaciones de clase DRAM como Redis y cachés KV, no solo a almacenamiento. Y, como era de esperarse, la inferencia empezó a superar al entrenamiento porque la industria tuvo que monetizar estos modelos, y surgieron los agentes para hacer de la memoria el juego completo.

Ese es el enfoque que aplico a la infraestructura de IA. Ya hemos visto esta película antes. FinOps en la nube surgió porque las empresas aprovisionaron infraestructura sin rigor de unidad económica y luego recibieron la factura. La IA está en la misma curva, avanzando más rápido. A medida que las empresas empujan inevitablemente contra el máximo de tokens con la llegada de facturas de consumo de API que superan con creces los presupuestos de tokens planificados, estamos presenciando el auge de AI FinOps. Este es el punto donde las organizaciones dejan de tratar la inferencia como una utilidad barata y comienzan a gestionar la eficiencia de tokens como una disciplina financiera. AI FinOps comienza con la tokenómica: optimizar cada capa de hardware y software de la pila de inferencia que impacta el costo unitario por token. Actualmente, el mayor desperdicio en esa pila son GPUs costosos y nuevos ASICs inactivos, esperando por memoria y datos (también llamado ‘decode’) en lugar de FLOPS (también llamado ‘prefill’). Quien solucione eso poseerá la siguiente fase de la IA.

La Casa Blanca mantiene confidenciales los detalles de su nuevo marco de seguridad de IA. ¿Cómo pueden las empresas prepararse para los requisitos regulatorios cuando aún no saben exactamente qué se probará o exigirá?

Las empresas no deberían esperar la lista de verificación final. Las pruebas específicas cambiarán, pero la obligación subyacente no: deberán demostrar lo que hizo su modelo de IA, qué datos tocó y cómo se comportó en un momento específico. Y esperar ya no es una opción a nivel global. La Ley de IA de la UE se volvió exigible este mes, y clasifica la mayor parte de la orquestación de agentes como de alto riesgo.

Eso significa que el trabajo de preparación es trabajo de infraestructura. La trazabilidad de datos, la observabilidad, la reproducibilidad y la capacidad de reconstruir el estado del modelo bajo demanda son críticos para que las empresas lo hagan bien. Finalmente, las organizaciones deben implementar modelos de salvaguarda antes de los resultados, con latencias y presupuestos de tokens asociados para las capas de defensa semántica. Si construye esas capacidades ahora, cualquier marco se convierte en un ejercicio de formateo. Esperar a las reglas definitivas implicará adaptar la responsabilidad a sistemas que nunca fueron diseñados para explicarse a sí mismos. Esa adaptación siempre resulta más costosa que incorporarla desde el principio.

En última instancia, la solución para construir IA segura es más IA, aplicada de manera óptima y muy intencionalmente.

¿Qué tipos de nuevas demandas de infraestructura podría generar la prueba de seguridad de IA, y en qué se diferirían esas cargas de trabajo de la capacitación o inferencia convencional de modelos?

El entrenamiento es una manguera de fuego. Se empujan enormes volúmenes de datos a través de un modelo en un patrón sostenido y predecible. Las pruebas de seguridad son lo contrario: miles de escenarios de evaluación, sondeos repetidos, comparaciones de comportamiento versión tras versión, y equipos rojos adversarios que nunca terminan.

Ese perfil importa. La capacitación y pruebas de seguridad son explosivas, con alta carga de lectura y comparativas. Generan y consumen enormes cantidades de estado intermedio. Los modelos de salvaguarda deben ser inherentemente heterogéneos y en capas, implementados dentro de estrictos presupuestos de latencia, amplificando las evaluaciones con esta nueva dimensión de criterios de seguridad. Para modelos tan avanzados o con capacidad cibernética, el perfil de carga es persistente 24/7 en lugar de episódico. No se ejecuta una prueba una sola vez y se archivan los resultados. Se ejecutan cargas de trabajo continuas de enjambres de agentes que compiten en producción por cómputo, memoria y ancho de banda de datos para esas aplicaciones críticas que protegen. Después de la calidad y la velocidad, la mayor parte de la infraestructura actual no está diseñada para este tercer principio.

También hay un problema de medición subyacente. La mayoría de los benchmarks de IA hoy en día ejecutan 8.000 tokens o menos, una sola solicitud, una respuesta. Bromeo diciendo que son benchmarks artificiales de inteligencia artificial. A mediados de 2026, las cargas de trabajo reales de agentes ejecutan de 100.000 a 400.000 tokens de contexto a través de miles de turnos. Si las evaluaciones de seguridad heredan esos benchmarks de juguete, estaremos certificando sistemas para un mundo que no existe. Los reguladores ya están construyendo una mayor capacidad aquí: NIST ha abierto el código de evaluación de seguridad de agentes, y los primeros resultados publicados muestran ataques novedosos de secuestro de agentes que tienen éxito a una tasa varias veces mayor que los baselines conocidos. Eso es exactamente el tipo de prueba continua, adversarial y costosa que espero que los marcos de seguridad converjan.

¿Deben las organizaciones construir capacidad de cómputo y datos excedente específicamente para futuras cargas de trabajo de cumplimiento y seguridad, o existe una forma más eficiente de diseñar ante esa incertidumbre?

Comprar GPUs en exceso y esperar a que la utilización se recupere solo deja capital atrapado en hardware que se deprecia.

La respuesta eficiente es una infraestructura que flexione entre cargas de trabajo de producción y de evaluación sin una pila separada. Eso es fundamentalmente un problema de datos. Si puede mover y reutilizar datos eficientemente, preservar el contexto entre cargas y mantener sus aceleradores ocupados realizando trabajo real, el cumplimiento se convierte en un costo incremental en lugar de una construcción paralela. La economía de la IA cada vez más depende de cuánto valor extrae de cada token, byte y vatio. Si lo hace bien, puede generar de 3 a 4 veces más valor con la misma infraestructura, o reducir su huella de rack hasta en un 75 %. El cumplimiento debe regirse por el mismo estándar.

Se informa que el marco actual se centra en modelos cerrados avanzados mientras excluye los modelos de peso abierto. ¿Qué desafíos de infraestructura o seguridad podrían surgir al tratar esas dos categorías de manera diferente?

Si trata los modelos cerrados y los de peso abierto de manera diferente, termina con dos marcos de cumplimiento para tecnologías que hacen lo mismo, y la brecha entre ellos es donde reside el riesgo.

Un modelo de peso abierto puede ajustarse y desplegarse en entornos donde el proveedor original no tiene visibilidad alguna. Regular al proveedor no sirve allí. Y la división ya es visible: los controles de exportación se aplicaron este año a los modelos cerrados de frontera más recientes, mientras que los modelos de peso abierto cruzan fronteras libremente y ahora ocupan los primeros puestos en los rankings públicos de capacidad. Sin embargo, la administración termina definiendo los modelos de frontera, la gobernanza no puede detenerse en el modelo mismo. Necesita visibilidad sobre dónde se ejecutan los modelos, a qué datos acceden, qué indicaciones, respuestas y metadatos se retienen, cómo se han modificado y si la infraestructura subyacente puede soportar IA gobernada a escala. Se requerirán nuevas actualizaciones a ISO27001 y SOC2.

Mi respuesta es confiar pero verificar. Si su infraestructura le brinda la capacidad de tokens, puede ejecutar salvaguardas heterogéneas contra cualquier modelo antes de que su salida se envíe: doméstico o extranjero, abierto o cerrado. La verificación objetiva supera la confianza ciega o la desconfianza total basada en el origen del modelo. A medida que los modelos abiertos se multiplican, esa capacidad de verificación vive en la capa de infraestructura, y ahí es donde las empresas se diferenciarán. La política puede decidir qué modelos están permitidos. La infraestructura decide si esos modelos pueden desplegarse de manera responsable y económica.

A medida que los agentes de IA se vuelven más autónomos y operan en contextos más extensos, ¿cómo cambia la cantidad de datos, memoria y cómputo que las organizaciones deben asignar a la monitorización y la seguridad?

Un chatbot es una indicación y una respuesta. Un agente autónomo es un proceso en ejecución. Toca docenas de sistemas, recupera información, toma decisiones intermedias y acumula estado durante horas o días antes de completar una tarea.

No se puede monitorizar eso mediante el muestreo de tokens o respuestas individuales. Hay que capturar la secuencia completa: lo que el agente sabía, cuándo lo sabía y qué hizo después. Cada hora que un agente funciona, su estado crece, al igual que la memoria, el movimiento de datos y la infraestructura necesaria para capturarlo y analizarlo. La monitorización deja de ser una característica de registro y se convierte en una carga de trabajo de primera clase con su propio presupuesto de recursos.

La defensa es donde esto se vuelve urgente. El problema de memoria de la IA se está convirtiendo en un problema de seguridad. Un agente de codificación puede iniciarse, entregarse y apagarse. Un agente de ciberseguridad no puede. Debe mantener el contexto a través de cambios de turno diarios en un centro de operaciones de seguridad, actualizaciones frecuentes de modelos y campañas de ataque multietapa sofisticadas que antes se extendían por semanas, pero ahora operan a velocidades de máquina coordinadas. Cuando la memoria de trabajo de esa IA se elimina y se vuelve a calcular desde cero cada pocos minutos, un agente que detectó un comportamiento anómalo en la primera hora de un incidente no lo recuerda en la segunda hora. Los atacantes no enfrentan ese problema. Sus agentes identifican y persiguen vulnerabilidades de forma persistente, y las cadenas de ataque ahora se completan a velocidades optimizadas por tokenómica, por lo que la defensa cibernética impulsada por IA debe operar de forma autónoma las 24 horas. Y esto no es teórico. Los proveedores de seguridad se están preparando ahora para agentes cibernéticos persistentes 24/7, y lo primero que descubren es que la economía no se parece en nada a las cargas de trabajo de chat. Algunas organizaciones necesitan esos agentes en el borde, en instalaciones donde no se puede instalar un rack de GPU o siquiera un enfriador este año. La verdadera prueba para la IA empresarial es la retención sostenida de contexto, no la inferencia puntual. Esto se convierte en una batalla de desgaste de tokens, y quien resuelva la memoria de contexto persistente a escala impulsará la primera aplicación horizontal asesina en IA empresarial: enjambres de agentes azules siempre activos.

Ha hablado sobre la creciente importancia de la “memoria de contexto” a medida que las cargas de trabajo de IA pasan más allá del chat simple hacia agentes persistentes. ¿Podría la memoria de contexto también volverse importante para auditar, reproducir o investigar el comportamiento de la IA?

Absolutamente, y es un caso de uso importante. Durante años, la memoria fue una historia de rendimiento: cuán rápido podía alimentar la GPU, cuánta contexto podía mantener. Una vez que los agentes actúan de forma autónoma, esa misma memoria se convierte en evidencia. Si un agente toma una decisión basada en el contexto que acumuló durante días, la indicación final y la salida le dicen casi nada sobre por qué actuó. La explicación reside en el estado acumulado.

En términos técnicos, la mayor parte de ese estado reside en la caché KV, y la industria todavía la trata como espacio desechable en lugar de datos duraderos. Si preserva ese estado y puede recuperarlo eficientemente, puede reconstruir lo que el sistema sabía en el momento en que actuó. Los equipos lo usarán primero para depuración, luego para evaluaciones de seguridad y, eventualmente, alguien lo necesitará en una investigación. Descartar la memoria de contexto equivale a desechar el único registro que explica por qué su IA hizo lo que hizo.

¿Podría la regulación de IA obligar finalmente a las empresas a retener significativamente más información sobre entradas del modelo, salidas, puntos de control, trazabilidad de datos y actividad de agentes? ¿Qué implicaría eso para la arquitectura de infraestructura de IA?

En dirección, sí. A medida que los sistemas de IA se vuelven más trascendentales, los requisitos de visibilidad se ampliarán para cubrir cada paso del pipeline. Ya se pueden ver las señales tempranas: los equipos planean retener la memoria de contexto obsoleta en capas de almacenamiento de objetos más baratas únicamente para fines de auditoría, antes de que cualquier regulación lo exija.

La autenticación de la monitorización con inmutabilidad es esencial. La manipulación de registros y otros artefactos forenses por agentes maliciosos se ha vuelto rutinaria, lo que requiere sistemas elaborados de verificación criptográfica que no sean vulnerables a objetivos de integridad centralizados y concentrados. Los simples registros de transparencia o cadenas de hash no son suficientes para defenderse de las capacidades de colusión de enjambres de agentes coordinados. Las arquitecturas de blockchain público, altamente descentralizadas, son ideales para esto, resaltando el a menudo pasado por alto valor de Integridad, en el centro de la tríada C-I-A de ciberseguridad.

La retención no es solo un problema abrumador de almacenamiento inmutable a escala. La parte difícil es mantener esa información confiable, organizada, indexada y recuperable lo suficientemente rápido como para ser útil bajo una fecha límite, ya sea impuesta por un regulador, una respuesta a incidentes o una sala de audiencias. Un petabyte de actividad de agentes que no puede consultarse es una responsabilidad, no un registro. El cambio arquitectónico pasa de “más almacenamiento” a una infraestructura diseñada alrededor de datos de IA persistentes, verificables objetivamente y consultables como carga de trabajo central.

Muchas organizaciones se centran en comprar más GPUs, pero ¿dónde ve los cuellos de botella de infraestructura menos evidentes emergiendo a medida que las cargas de trabajo de IA escalan y los requisitos de seguridad se vuelven más exigentes?

La GPU acapara los titulares porque no es un ítem presupuestario insignificante. Pero las GPUs y, especialmente, los nuevos aceleradores optimizados para decodificación (ASIC+SRAM) rara vez son la verdadera limitación. El ancho de banda de memoria, la gravedad y movimiento de datos, el rendimiento de almacenamiento y la red determinan si esos aceleradores están realizando trabajo productivo o esperando sin utilizarse.

A medida que la IA se vuelve más pesada en contexto, la pared de memoria se vuelve el límite definitorio. Puede seguir añadiendo GPUs, pero si pasan sus ciclos volviendo a calcular tokens o moviendo contexto entre sistemas, está pagando por trabajo desperdiciado, repetidamente. Escalar la pared de memoria significa hacer que la capa de datos se comporte como almacenamiento compartido, pero con rendimiento a velocidad de memoria real. Esa barra de velocidad adyacente a HBM importa para la ola de soluciones de descarga de caché KV que llegan ahora: cualquiera de ellas debe ofrecer un rendimiento de clase memoria verdadera para que la tokenómica tenga sentido. El valor de retención para la caché KV es una discusión de centro de costos, secundaria al centro de beneficios. Y si leer el contexto en caché es más lento que volver a calcularlo, la caché no tiene valor en la ecuación empresarial. Lo que importa no es cuántas GPUs posee, sino cuán productiva es cada una. La economía de la IA se reduce al valor que extrae de cada token, byte y vatio, y los requisitos de seguridad solo elevarán la apuesta en esa matemática.

De cara al futuro, ¿espera que la seguridad y el cumplimiento de IA se conviertan en una carga de trabajo de infraestructura distinta, similar a cómo la ciberseguridad evolucionó a una capa dedicada de la tecnología empresarial?

Veremos que la seguridad y el cumplimiento de IA se convierten en una carga de trabajo distinta, y el paralelismo con la ciberseguridad funciona en ambos sentidos. La seguridad se convirtió en una capa propia una vez que la industria aceptó que no podía ser un ejercicio ocasional. La industria de seguros cibernéticos lo hizo obligatorio. La seguridad de IA está en la misma trayectoria obligatoria a medida que los modelos se vuelven más capaces y autónomos.

Pero debemos aprender de los errores de la seguridad. Se convirtió en un complemento: una pila separada, un presupuesto separado, un equipo separado que descubre problemas después de los hechos. La infraestructura de seguridad no debe repetir ese error. La monitorización, evaluación, auditabilidad y retención inmutable deben pertenecer a la propia infraestructura de IA, co-diseñadas desde el inicio.

Esta es la parte que la mayoría pasa por alto: la IA segura requiere más IA. Los modelos de salvaguarda no son gratuitos. Deben entrenarse, ajustarse y ejecutarse continuamente en cada paso del tiempo de ejecución del agente. Los presupuestos de latencia de token lo hacen tangible: cada respuesta tiene una ventana fija, y cuantos más tokens pueda procesar dentro de esa ventana, más verificaciones puede ejecutar antes de que la salida salga al exterior. Y la verdadera amenaza de los modelos de frontera es su aplicación agente. Los agentes funcionan como bucles de inferencia de alto volumen, realizando llamadas repetidas a modelos durante horizontes largos. Cada bucle observa, orienta, decide, actúa, y cada paso consume tokens. Eso convierte la seguridad de IA en una guerra de desgaste de tokens. Los atacantes despliegan enjambres de agentes rojos, los defensores despliegan enjambres de agentes azules, y el lado que pueda generar más tokens por dólar y por vatio gana. La tokenómica está en la ruta crítica tanto del ataque como de la defensa. Esto dejó de ser un experimento de pensamiento este verano, cuando un ataque de enjambre de agentes rojos contra un importante repositorio de modelos asustó a la industria y se formó una alianza de IA segura dedicada en cuestión de días. Mientras tanto, los volúmenes siguen compounding: el procesamiento de tokens de la industria ha pasado de billones a cuatrillones.

Una vez que la seguridad se convierta en un requisito siempre activo, sus costos de cómputo, memoria y datos dejan de ser un gasto general. Se convierten en parte de la economía unitaria fundamental de ejecutar IA. Las empresas que internalicen eso temprano tratarán la seguridad como una entrada de diseño. Todos los demás la tratarán como un impuesto.

Gracias por la excelente entrevista, lectores que deseen obtener más información deberían visitar WEKA.