Unite AI: Nikunj Bajaj, cofundador y director ejecutivo de TrueFoundry – Serie de entrevistas

Nikunj Bajaj es cofundador y CEO de TrueFoundry, donde lidera la visión y estrategia de la empresa en la creación de plataformas de IA fiables y de nivel empresarial. Con experiencia en el escalado de productos y equipos tecnológicos, se centra en permitir que las organizaciones desplieguen y operen sistemas de IA de forma segura y eficiente. Escribe sobre la adopción de IA empresarial, la estrategia de plataformas de IA y las tendencias emergentes en la producción de IA.

TrueFoundry es una plataforma de infraestructura de IA empresarial que ayuda a las organizaciones a crear, desplegar, gobernar y escalar aplicaciones de aprendizaje automático e IA generativa en entornos basados en Kubernetes, ya sea en la nube, en instalaciones locales o en modelos híbridos, con controles estrictos de gobernanza, seguridad y costes. Combina una puerta de enlace de IA (AI Gateway) para centralizar el acceso a modelos, LLM y flujos de trabajo de agentes con herramientas para el ajuste fino, despliegue, monitorización y escalado automático de modelos, con el objetivo de simplificar las operaciones de aprendizaje automático (MLOps) y acelerar el tiempo de obtención de valor para los equipos de ciencia de datos e ingeniería. El enfoque de TrueFoundry, centrado en el desarrollador y agnóstico respecto a la nube, enfatiza el cumplimiento normativo y la flexibilidad empresarial, permitiendo a los equipos gestionar cargas de trabajo de IA complejas sin depender de un único proveedor, al tiempo que se aplican estándares como SOC 2, HIPAA e ITAR.

Antes de fundar TrueFoundry, trabajó en investigación de aprendizaje automático, producción de IA en Facebook y sistemas de recomendación a gran escala. ¿Qué experiencias le impulsaron más directamente a crear una empresa de infraestructura de IA empresarial y qué problema sentía que no se estaba abordando en aquel momento?

En Meta, considerábamos el aprendizaje automático como un caso especial de software, y la IA generativa como un caso especial de aprendizaje automático, lo que resultaba en una pila vertical con el software en la base, el aprendizaje automático en el medio y la IA generativa en la parte superior. En esta configuración, si soy un desarrollador de aprendizaje automático, los modelos que construyo siguen el mismo patrón de despliegue que el resto del software, lo que hace que el escalado de los sistemas sea muy sencillo.

Sin embargo, la mayoría de las empresas desplegaban pilas paralelas, lo que significa que tenían pilas separadas para software, aprendizaje automático e IA generativa. En el momento en que se tienen estas pilas paralelas, el escalado se vuelve más complejo debido a las transferencias necesarias entre el aprendizaje automático y el mundo del software.

Nuestro equipo siempre ha trabajado en la intersección de la creación de modelos de aprendizaje automático y la infraestructura para los mismos, por lo que teníamos un punto de vista único que podíamos aportar a las empresas para implementar pilas verticales similares y adaptarlas a sus requisitos específicos. También teníamos la hipótesis, hacia finales de 2021, de que el aprendizaje automático se acercaba a un punto de inflexión y que, cuando llegara, más empresas necesitarían una pila integrada verticalmente para desplegar y escalar estos sistemas de manera efectiva. Esto es lo que finalmente nos llevó a fundar TrueFoundry, y nuestra hipótesis era correcta. La adopción de la IA se aceleró tras el lanzamiento de ChatGPT a finales de 2022.

A medida que los sistemas de IA pasan de la experimentación a las operaciones cotidianas, ¿qué ha cambiado en la forma en que las organizaciones deberían pensar sobre la fiabilidad y los fallos?

Lo que está en juego con la IA generativa es significativamente mayor en comparación con los sistemas de aprendizaje automático tradicionales. A medida que estos sistemas pasan a producción, las organizaciones se enfrentan a un nivel mucho mayor de ambigüedad e indeterminación, ya que los LLM son estocásticos por naturaleza. Los sistemas de agentes construidos sobre ellos añaden aún más ambigüedad.

Además, los fallos ya no son binarios. En lugar de que los sistemas simplemente fallen o no, muchos problemas aparecen como fallos parciales o degradaciones silenciosas. Los sistemas pueden responder con mayor latencia, calidad degradada o comportamiento incorrecto con el paso del tiempo. En muchos casos, estas degradaciones pueden ser más difíciles de detectar y, a veces, incluso más perjudiciales que una interrupción total.

Las organizaciones deben pensar en la fiabilidad no solo en términos de tiempo de actividad, sino también de degradación del rendimiento a lo largo del tiempo.

TrueFailover se lanzó en medio de una ola de interrupciones de alto perfil en servicios de nube e IA. ¿Qué eventos recientes dejaron claro que la fiabilidad de la IA había pasado de ser algo "deseable" a un requisito arquitectónico fundamental?

Uno de nuestros clientes del sector sanitario, que procesa solicitudes de pacientes en tiempo real y sensibles al tiempo relacionadas con recetas médicas, se vio afectado por una interrupción causada por un fallo en el modelo. Sus flujos de trabajo generan miles de dólares de ingresos por segundo, y la interrupción afectó a algunos de estos flujos críticos. Como cliente inicial de TrueFailover, pudimos ayudar con una recuperación rápida y el impacto fue contenido.

Incidentes como este plantean una pregunta importante. A medida que aumenta lo que está en juego con los sistemas de IA generativa, ¿por qué los procesos de recuperación siguen siendo en gran medida manuales? Esto reforzó la idea de que los sistemas deben construirse asumiendo que los fallos ocurrirán y deben diseñarse para corregirse automáticamente. La fiabilidad también debe integrarse en la propia pila de IA mediante el uso de puertas de enlace de IA (AI Gateways), que pueden proporcionar enrutamiento centralizado, observabilidad, barreras de seguridad y cambio inteligente de modelos entre proveedores.

Muchas interrupciones de IA todavía se consideran contratiempos técnicos. ¿Dónde ve que empiezan a surgir los verdaderos costes económicos y humanos cuando los sistemas de IA fallan?

La IA empresarial ha evolucionado hasta el punto en que estos contratiempos ya no afectan solo a los flujos de trabajo internos. Hoy en día, las interrupciones y degradaciones afectan a la percepción pública y a los beneficios de forma directa e inmediata, porque los casos de uso en producción están ahora orientados al cliente. Este cambio de las pruebas internas a aplicaciones públicas de alto riesgo es la razón por la que vemos una mayor demanda de atención y supervisión por parte de los ejecutivos.

A medida que los sistemas de IA se integran más profundamente en los flujos de trabajo operativos, las interrupciones ya no son solo problemas técnicos. Cada vez tienen más consecuencias directas para el negocio, el cliente y la reputación.

En entornos de misión crítica como farmacias, operaciones sanitarias o atención al cliente, ¿con qué rapidez puede el tiempo de inactividad de la IA convertirse en un riesgo operativo o reputacional?

En entornos de misión crítica, la escalada ocurre casi de inmediato porque estos sistemas respaldan flujos de trabajo en tiempo real y sensibles al tiempo. Incluso una interrupción breve puede detener procesos críticos, retrasar la prestación de servicios o interrumpir sistemas posteriores que dependen de esos resultados, creando efectos operativos en cascada en toda la organización.

En sectores como el sanitario, el impacto se extiende más allá de la interrupción operativa hacia la experiencia del cliente y los resultados del servicio. Si un paciente no puede obtener su receta a tiempo, puede haber consecuencias reales. Esto no solo es un problema para el paciente, sino que también puede dañar la reputación de una farmacia o proveedor de atención médica. En entornos de misión crítica donde la confianza es un factor, es fundamental que los sistemas permanezcan en línea. Por eso las organizaciones reconocen cada vez más que los sistemas de IA deben diseñarse asumiendo que ocurrirán fallos y que los mecanismos de recuperación deben activarse automáticamente para minimizar el riesgo.

Ha dicho que muchos equipos diseñan pensando en la capacidad en lugar de en la continuidad. ¿Por qué cree que la resiliencia ha sido históricamente despriorizada en el diseño de sistemas de IA?

Esto se debe en gran medida a los incentivos dentro de las organizaciones. Las nuevas capacidades son visibles y emocionantes. Permiten demostraciones, funciones y posibilidades de producto que el liderazgo puede apreciar de inmediato.

La continuidad, por definición, es invisible cuando las cosas funcionan bien. Debido a esto, los sistemas de recompensa tienden a inclinarse hacia el lanzamiento de nuevas funciones en lugar de garantizar que nada se rompa. Como resultado, las organizaciones suelen invertir de manera desproporcionada en el desarrollo de capacidades en lugar de en la ingeniería de resiliencia.

A medida que las empresas dependen cada vez más de modelos y API externos, ¿qué nuevas fragilidades se están introduciendo en la pila de IA que los líderes quizás aún no comprendan del todo?

Los LLM son fundamentalmente recursos compartidos y las empresas no son sus propietarias como lo son de la infraestructura tradicional. Además, sistemas empresariales críticos funcionan sobre sistemas externos que no han sido totalmente probados con el tiempo. Los propios LLM evolucionan rápidamente, lo que significa que no se puede responsabilizar a un proveedor de modelos por cuestiones como la latencia o una ligera disminución en el rendimiento, ya que iteran sobre su investigación muy rápido.

Debido a que los LLM son recursos compartidos, la latencia puede aumentar porque otro consumidor de estos modelos realiza una acción específica. Existen muchos puntos de falla que se introducen debido a la naturaleza fundamental de los LLM, y las empresas en este nuevo mundo simplemente no tienen el control total. Sin un control total, lo mejor que puede hacer una empresa es crear suficientes redundancias para diseñar un sistema resiliente.

Sin centrarse en productos específicos, ¿cómo deberían las organizaciones replantear la arquitectura de IA para asumir el fallo en lugar de tratar las interrupciones como casos excepcionales poco frecuentes?

Las organizaciones deberían volver a los principios básicos del diseño de sistemas distribuidos. Los sistemas de software se construyeron bajo la premisa de que los componentes de red y las máquinas fallarían, y que una región entera podría quedar fuera de servicio.

Los sistemas de IA no deberían ser diferentes. Debemos asumir que los proveedores de modelos experimentarán problemas de latencia, degradaciones o interrupciones, e incorporar redundancia para que las aplicaciones sigan siendo resilientes ante diferentes escenarios de falla.

¿Espera que la resiliencia de la IA se convierta en un factor decisivo en la selección de plataformas y proveedores, de forma similar a como el tiempo de actividad y la redundancia definieron las decisiones sobre infraestructura en la nube?

A medida que más sistemas de IA pasen a producción, la resiliencia será un requisito indispensable. Si un proveedor no puede mostrar sus gráficos y métricas sobre tiempo de actividad y resiliencia general, ni siquiera será considerado. Una vez que la resiliencia se convierta en una expectativa básica entre los proveedores, los factores decisivos se desplazarán hacia la experiencia del usuario, la optimización del rendimiento, la observabilidad y las capacidades de producto de alto nivel. Con el tiempo, componentes como una puerta de enlace de IA (AI Gateway) y las capacidades de conmutación por error automatizada se convertirán en elementos fundamentales de la infraestructura de IA empresarial.

Mirando hacia el futuro, ¿qué significa realmente una IA "lista para producción" en un mundo donde se espera que la IA esté disponible continuamente, no solo que sea útil ocasionalmente?

Los sistemas de IA listos para producción deben ser observables, controlables y recuperables. Estos tres requisitos deben cumplirse.

Para que la IA de producción sea observable, los equipos necesitan una visibilidad profunda del comportamiento del modelo, la latencia, las tasas de error, el uso de tokens, la deriva y los patrones de falla. Sin una observabilidad sólida, resulta muy difícil detectar degradaciones antes de que los usuarios comiencen a notarlas.

Para que los sistemas sean controlables, esto incluye la gestión del tráfico, la limitación de velocidad, las barreras de seguridad (guardrails), la aplicación de políticas y el enrutamiento inteligente entre modelos y proveedores. Aquí es donde una puerta de enlace de IA se vuelve fundamental, actuando como un plano de control centralizado que aplica barreras de seguridad, proporciona una gobernanza coherente y permite el cambio dinámico de modelos cuando el rendimiento o la fiabilidad disminuyen.

Y, por último, en cuanto a la capacidad de recuperación, los sistemas deben construirse asumiendo que los componentes pueden romperse parcial o totalmente, ya sea debido a interrupciones del proveedor, degradación de la calidad del modelo, límites de velocidad o entradas inesperadas de actores malintencionados. La conmutación por error automatizada y los mecanismos de autorreparación deben ser nativos de la arquitectura, no manuales ni activados solo después de que algo sale mal.

Esta es la dirección hacia la que trabajamos en TrueFoundry. Los proveedores que definan la preparación para producción de esta manera, combinando observabilidad, control centralizado y recuperación automatizada, se ganarán la confianza de los clientes a largo plazo y podrán seguir resolviendo nuevos problemas a medida que surjan.

Sobre TrueFoundry:

TrueFoundry ofrece una puerta de enlace de IA de nivel empresarial que abarca una puerta de enlace de LLM, una de MCP y una de agentes, lo que permite a las empresas conectar, observar y gobernar de forma segura el acceso a modelos, herramientas, barreras de seguridad y agentes desde un único plano de control. La puerta de enlace de IA permite cargas de trabajo de agentes que son seguras, eficientes y preparadas para el futuro mediante conexiones unificadas y componibles entre proveedores.

Más allá de la capa de puerta de enlace, TrueFoundry permite a las organizaciones implementar y entrenar LLM personalizados en GPU, alojar servidores MCP y ejecutar agentes personalizados, todo a través de una interfaz nativa de Kubernetes. Admite instalaciones locales y en VPC tanto para la puerta de enlace de IA como para los entornos de implementación. TrueFoundry garantiza el cumplimiento de nivel empresarial con los estándares SOC 2, HIPAA e ITAR. Con escalado automático, almacenamiento en caché y optimización de recursos integrados, TrueFoundry permite a las organizaciones construir, implementar y gobernar sistemas de IA de forma segura, eficiente y sobre una pila preparada para el futuro. Para obtener más información, visite truefoundry.com