La gobernanza de la IA no puede ser una ocurrencia tardía

Abhishek Ranjan es el director de tecnología de Apna y Blue Machines, donde participa profundamente en la transformación tanto de la fuerza laboral humana como de la fuerza laboral de IA.

Nos reunimos con él para hablar sobre la gobernanza en los flujos de trabajo de IA. Esto fue lo que dijo.

La tecnología junto a los seres humanos

Soy Abhishek Ranjan. Soy el director de tecnología de Apna y Blue Machines. Dos mundos muy conectados, aunque diferentes, han dado forma a mi trayectoria hasta este momento de transformación impulsada por la IA.

En Apna, desarrollamos soluciones para la fuerza laboral humana. Apna es uno de los unicornios de más rápido crecimiento de la India, con más de 60 millones de usuarios en la plataforma. A esa escala, observamos muy de cerca a la fuerza laboral de la India. Vemos a millones de personas que buscan mejores oportunidades, a empleadores que intentan contratar más rápido, diferentes idiomas, distintos niveles de habilidades y diversos grados de acceso y confianza digitales.

En Blue Machines, desarrollamos soluciones para la fuerza laboral de IA. Nos centramos en la IA de voz empresarial y registramos millones de minutos todos los días. No desarrollamos simplemente bots que responden preguntas. Creamos trabajadores de IA capaces de hablar con los clientes, comprender el contexto, recibir comentarios, mejorar con el tiempo y ejecutar flujos de trabajo empresariales reales.

He visto cómo la tecnología ayuda a las personas a encontrar trabajo, crecer y participar en la economía. Y ahora veo que la IA misma se está convirtiendo en un nuevo tipo de fuerza laboral que puede trabajar junto a los seres humanos.

Por eso, para mí, este momento no se trata únicamente de utilizar la IA para aumentar la productividad o escribir código más rápido. Se trata de replantearnos cómo operan las empresas y cómo se realiza el trabajo.

La arquitectura de dos empresas muy diferentes

La arquitectura de Apna está construida como una gran plataforma de mercado. Contamos con sistemas para consumidores, sistemas para empleadores, plataformas de datos, sistemas de IA y de emparejamiento, búsqueda, comunicación, capas contra el fraude y de confianza, y ahora también capacidades de reclutamiento mediante IA y preparación de entrevistas con IA. El modelo de implementación prioriza la nube, es altamente escalable y está diseñado para ofrecer una alta disponibilidad, ya que millones de usuarios y miles de empresas utilizan la plataforma.

La organización de ingeniería cuenta con más de 100 personas que trabajan en equipos de ingeniería de producto, backend, frontend, dispositivos móviles, datos, IA, infraestructura, seguridad y plataforma. Nos centramos no solo en desarrollar funcionalidades, sino también en crear sistemas fiables capaces de operar a una escala enorme.

Blue Machines es un tipo diferente de organización tecnológica. Se centra en la IA de voz empresarial y en los flujos de trabajo agénticos. Estamos construyendo trabajadores de IA capaces de hablar, razonar, realizar acciones, integrarse con sistemas empresariales y mejorar mediante los comentarios. Hoy ya operamos a una escala considerable, con millones de minutos de IA de voz registrados cada día.

La arquitectura de Blue Machines es más orientada al tiempo real y nativa de la IA. Incluye infraestructura de voz, telefonía, conversión de voz a texto, razonamiento mediante modelos de lenguaje de gran tamaño, conversión de texto a voz, orquestación de flujos de trabajo, integraciones, análisis, observabilidad y sistemas de evaluación. La complejidad del producto es alta porque la IA de voz empresarial debe funcionar en producción, en conversaciones reales, con baja latencia, alta precisión, medidas de protección para el cumplimiento normativo y resultados empresariales claros.

En Blue Machines, un equipo central de cuatro ingenieros construyó una plataforma distribuida de orquestación de voz en cuestión de semanas. También contamos con un equipo de investigación muy experimentado que trabaja intensamente en IA de voz, evaluación de agentes, razonamiento, latencia, sistemas multilingües y mejora de los agentes con el tiempo. Esa profundidad investigadora es importante porque la IA de voz empresarial no puede resolverse únicamente conectando modelos. Requiere una sólida ingeniería de producto, una sólida ingeniería de sistemas y una sólida investigación aplicada en IA.

En general, la organización tecnológica que dirijo se encuentra en la intersección de las plataformas a gran escala y los sistemas nativos de la IA.

Cómo la IA bien gobernada mejora el ciclo de vida del software

Durante el último año, la IA ha cambiado la forma en que desarrollamos, probamos y lanzamos tecnología.

Anteriormente, nuestro proceso de lanzamiento era más tradicional. Los ingenieros desarrollaban funcionalidades, creaban solicitudes de incorporación de cambios, pasaban por revisiones entre pares, ejecutaban casos de prueba y, después, las publicaban mediante el proceso habitual de implementación. Funcionaba, pero la velocidad dependía de los ciclos de revisión humana, el control de calidad manual y la confianza del equipo en el lanzamiento.

A medida que la programación asistida por IA se convirtió en una parte más importante de la ingeniería, la adoptamos y pronto nos dimos cuenta de que las mejoras de velocidad por sí solas no eran suficientes. La IA puede ayudar a los ingenieros a escribir código más rápido, pero, a menos que mejore la gobernanza, también puede generar más errores ocultos, casos límite omitidos o abstracciones deficientes.

Por eso, cambiamos el modelo operativo.

1. Añadimos una capa de revisión de solicitudes de incorporación de cambios asistida por IA. Cada solicitud se sometía a comprobaciones de lógica de riesgo, casos límite omitidos, rupturas de contratos de API, problemas de seguridad, riesgos de migración y una cobertura de pruebas insuficiente antes de la revisión humana. Esto redujo los errores evidentes antes de la revisión.
2. Reforzamos las barreras de CI. Un cambio no podía avanzar únicamente porque el código pareciera correcto. Tenía que superar pruebas unitarias, pruebas de integración, análisis de estilo, comprobaciones de seguridad, pruebas de contratos de API y conjuntos de pruebas de regresión para el área del producto afectada.
3. Desarrollamos conjuntos de regresión más sólidos para los flujos de trabajo críticos. Por ejemplo, añadimos casos de prueba para escenarios de usuarios reales, casos límite, comportamiento multilingüe, gestión de errores y resultados empresariales.
4. Cambiamos la gobernanza de las instrucciones. Hablaremos más de esto en un momento.
5. Hicimos obligatorios los lanzamientos canarios para las áreas de alto riesgo. En lugar de publicar para todos, publicamos para un pequeño porcentaje del tráfico, supervisamos los errores, la latencia, la conversión, los abandonos, la calidad de los agentes y el impacto en los clientes, y después promocionamos el cambio o revertimos la versión.
6. Añadimos una mejor observabilidad. Cuando algo fallaba, queríamos saber exactamente qué versión del código, versión de las instrucciones, modelo, flujo de trabajo o dependencia lo había provocado.

El impacto ha sido muy visible. Nuestra velocidad de lanzamiento aumentó significativamente. Los equipos que antes publicaban lanzamientos más grandes y agrupados ahora realizan lanzamientos más pequeños y frecuentes. En algunas áreas, la frecuencia de lanzamiento aumentó casi entre 2 y 3 veces porque las comprobaciones están más automatizadas y la confianza es mayor. Y así fue como un equipo de cuatro personas construyó una plataforma distribuida compleja en cuestión de semanas.

El número de problemas en producción también disminuyó porque cada lanzamiento es más pequeño, está mejor probado y es más fácil de revertir. Observamos una reducción significativa de los errores en producción, especialmente en las áreas donde las regresiones automatizadas y los lanzamientos canarios son ahora obligatorios. Actualmente, los defectos están casi un 40 % por debajo de la línea base original.

La IA por sí sola aporta velocidad. La IA con gobernanza aporta velocidad y calidad.

Por qué las instrucciones deben tratarse como código

Abhishek comparte

En los sistemas de IA, también comenzamos a tratar las instrucciones como código… Esta ha sido una mejora importante. Sabemos qué instrucción estaba activa, qué cambió, qué mejoró y si los resultados para los clientes mejoraron.

En los sistemas de IA, también comenzamos a tratar las instrucciones como código.

Ahora versionamos, revisamos, probamos, promovemos las instrucciones entre entornos y las implementamos por etapas. Las instrucciones ya no se tratan como pequeñas actualizaciones de configuración. Se someten a conversaciones de prueba, casos límite, comprobaciones multilingües, comprobaciones de latencia, comprobaciones de cumplimiento y comprobaciones de resultados empresariales.

Podemos publicar primero una nueva instrucción o flujo de trabajo de un agente para un pequeño porcentaje del tráfico, observar los resultados y, después, promoverlo si las métricas parecen mejores.

Esta ha sido una mejora importante. Antes, era difícil saber si un cambio en una instrucción mejoraba el agente o simplemente modificaba su comportamiento. Ahora podemos comparar las versiones de forma más objetiva. Sabemos qué instrucción estaba activa, qué cambió, qué mejoró y si los resultados para los clientes mejoraron.

El cambio más importante es que todo el sistema tecnológico se volvió más automatizado, más medible y mejor gobernado.

Un flujo de trabajo de lanzamiento de ingeniería agéntica

Utilizamos un flujo de trabajo de lanzamiento de ingeniería agéntica, con la participación de personas en puntos clave.

Este flujo de trabajo no funciona para todos los lanzamientos. Para cambios de plataforma muy complejos, cambios profundos de arquitectura o sistemas sensibles, seguimos utilizando un proceso más tradicional, dirigido por personas. Sin embargo, para algunas áreas del producto, especialmente los flujos de trabajo que evolucionan más rápido, se ha convertido en la forma predeterminada de desarrollo.

Este es el flujo de trabajo:

1. El proceso comienza cuando llega un requisito de producto o un problema de ingeniería. Un agente de planificación de IA lee el requisito, lo divide en tareas, identifica dependencias, señala las áreas de riesgo y sugiere un plan de implementación. El ingeniero revisa el plan, corrige las suposiciones y decide el enfoque final.
2. A continuación, un agente de programación genera código, refactoriza módulos, escribe código repetitivo y crea pruebas unitarias y de integración. Un agente de revisión comprueba la solicitud de incorporación de cambios para detectar lógica riesgosa, casos límite faltantes, problemas de seguridad, incumplimientos del contrato de la API y deficiencias en las pruebas.
3. Después, un agente de pruebas crea escenarios de regresión y valida los casos límite. En los flujos de trabajo de IA, también ejecuta evaluaciones de indicaciones, pruebas de conversaciones, comprobaciones multilingües, comprobaciones de latencia y comprobaciones de resultados empresariales.
4. Luego, el agente de lanzamiento recomienda si el cambio es seguro para una implementación canaria basándose en los resultados de las pruebas, el área afectada, los fallos anteriores y la preparación de la observabilidad. Sin embargo, las personas siguen aprobando las promociones críticas, especialmente si el cambio afecta a los ingresos, la experiencia del cliente, la seguridad o la infraestructura principal.
5. Una vez lanzado, el agente de monitorización supervisa los errores, la latencia, la conversión, los abandonos, la calidad del agente y el impacto en los clientes. Si algo parece incorrecto, recomienda revertir el cambio, abre un incidente, resume los registros y crea un primer borrador del RCA.

Este flujo de trabajo es agéntico, pero no autónomo a ciegas. Los agentes de IA planifican, programan, revisan, prueban, lanzan, monitorizan y resumen. Las personas aprueban, cuestionan, priorizan y asumen la responsabilidad de la decisión final.

En qué destacan Claude Code y Cursor

Mis herramientas favoritas son Claude Code y Cursor, según el flujo de trabajo.

Cursor destaca cuando los ingenieros quieren una integración profunda de la IA en su IDE para la programación diaria, la refactorización, la comprensión del código base y una implementación más rápida.

Claude Code resulta extremadamente útil para tareas más agénticas: comprender códigos base grandes, realizar cambios en varios archivos, generar pruebas, corregir problemas e iterar como un socio de ingeniería.

Por qué la IA aporta capacidad y las personas aportan criterio

Ahora dependemos en gran medida de la IA para todo lo que mejora la velocidad, la cobertura o la coherencia, pero no para las tareas que requieren criterio, responsabilidad o decisiones con consecuencias a largo plazo.

Por ejemplo, la IA ahora nos ayuda en la revisión de código, la generación de casos de prueba, la cobertura de regresión, la documentación, la depuración, el análisis de registros e incluso la clasificación de incidentes. Puede identificar rápidamente rutas de código riesgosas, casos límite faltantes, posibles problemas de seguridad o patrones en fallos de producción. En los sistemas de IA, también nos ayuda a comparar versiones de indicaciones, evaluar conversaciones y comprender dónde está fallando un agente.

Pero las decisiones finales siguen siendo humanas. Estos son algunos ejemplos:

• Las decisiones de arquitectura deben seguir siendo humanas porque implican concesiones relacionadas con la escala, el coste, la fiabilidad, las capacidades del equipo y la dirección del producto a largo plazo.
• La RCA de extremo a extremo puede recibir asistencia de la IA, pero las personas aún deben conectar los puntos, validar la hipótesis y decidir la solución.
• La priorización del trabajo pendiente sigue siendo humana porque requiere contexto del cliente, estrategia empresarial y criterio sobre lo que realmente importa.
• Las revisiones de seguridad utilizan IA, pero es necesario contar con criterio experto. La IA puede señalar problemas, pero también puede generar falsos positivos o pasar por alto riesgos relacionados con el contexto empresarial. Las personas conservan la responsabilidad porque el riesgo y la rendición de cuentas son demasiado elevados.

Ejemplos reales de fallos de la IA en el criterio técnico

A continuación, se presentan un par de ejemplos de la importancia del criterio humano.

El primero implicó picos de latencia de nivel milisegundo en nuestra canalización de voz. La IA comentó correctamente el problema e identificó que la latencia en una ruta podía convertirse en un problema. Pero el código que sugirió era incorrecto. Parecía limpio, pero habría creado un cuello de botella diferente bajo carga. Un ingeniero humano intervino, comprendió el comportamiento en tiempo de ejecución y lo corrigió adecuadamente.

Otro ejemplo surgió durante la investigación de incidentes en producción. Varios sistemas posteriores estaban fallando y la IA seguía analizando esos sistemas de forma independiente, sugiriendo optimizaciones. Pero ya sabíamos que el problema real era una dependencia anterior que había fallado primero. La IA estaba confundiendo los fallos visibles con la causa raíz.

Aquí es donde la IA todavía tiene dificultades. Puede leer registros, resumir trazas, sugerir soluciones y acelerar la depuración. Pero en sistemas distribuidos complejos, puede pasar por alto la causalidad, el momento de los eventos y el contexto del sistema en su conjunto.

Por qué los equipos se están volviendo más reducidos y versátiles

La IA ha cambiado más el perfil de contratación que el organigrama.

Antes contratábamos buscando una especialización funcional más limitada: backend, frontend, control de calidad, DevOps, datos, etc. Esas habilidades siguen siendo importantes, pero ahora valoro a los ingenieros que pueden trabajar en toda la pila tecnológica, utilizar la IA en profundidad y pasar del problema a producción con mucha menos supervisión.

Los mejores ingenieros ya no se limitan a escribir código. Diseñan flujos de trabajo, utilizan la IA para la implementación, generan pruebas, revisan resultados, depuran más rápido y piensan en la calidad de las versiones.

Por eso, el nivel exigido en la contratación se desplazó hacia ingenieros con un alto sentido de la responsabilidad y un gran criterio. Personas capaces de hacer las preguntas adecuadas, verificar los resultados de la IA, comprender profundamente los sistemas y publicar de forma independiente.

También ha reducido la necesidad de contar con equipos grandes en algunas áreas. Ahora, un equipo más pequeño con un sólido aprovechamiento de la IA puede realizar un trabajo que antes requería muchas más personas.

Por qué la IA dificulta la formación de ingenieros sin experiencia

Abhishek Shares

No creo que prohibir la IA u obligar a la gente a programar como si estuviéramos en 2010 sea la respuesta. Eso sería un error. Pero tampoco creo que hayamos resuelto por completo cómo desarrollar un criterio de ingeniería profundo cuando la IA realiza gran parte del trabajo preliminar. Por ahora, mi mejor respuesta es hacer visible la comprensión.

¿Cómo formamos a los ingenieros sin experiencia en la era de la IA? Todavía no tengo una respuesta perfecta.

Cuando empezamos, los entornos de desarrollo integrados nos ayudaron. Después, Google nos ayudó. Luego, Stack Overflow nos ayudó. Pero en todas esas etapas, aún tenías que esforzarte para resolver el problema. Tenías que comprender la respuesta, adaptarla, depurarla y aprender por qué funcionaba.

Con la IA y la programación por intuición, podemos saltarnos ese esfuerzo. Un ingeniero sin experiencia puede generar código funcional sin comprender realmente el sistema, las compensaciones ni los modos de fallo. Eso me preocupa.

No creo que prohibir la IA u obligar a la gente a programar como si estuviéramos en 2010 sea la respuesta. Eso sería un error. Pero tampoco creo que hayamos resuelto por completo cómo desarrollar un criterio de ingeniería profundo cuando la IA realiza gran parte del trabajo preliminar.

Por ahora, mi mejor respuesta es hacer visible la comprensión. Los ingenieros deberían poder explicar por qué funciona el código, dónde puede fallar, qué pruebas son importantes, qué ocurre a escala y cómo lo depurarían en producción.

Cómo gestionar el uso de tokens

El coste también ha sido un desafío de la IA.

El uso de tokens parece inofensivo al principio, pero cuando la IA interviene en la programación, las revisiones, las pruebas, la depuración y los flujos de trabajo con agentes, el coste puede crecer muy rápidamente.

Por eso, ahora debemos medir el rendimiento de la inversión por flujo de trabajo y utilizar una orquestación más inteligente. No todas las tareas necesitan el modelo más caro.

El futuro implica utilizar el modelo adecuado para cada tarea.

Por qué los CTO deben avanzar rápidamente, con controles

Este es mi consejo: construyan rápido. Experimenten rápido. Incorporen la IA a los flujos de trabajo reales de ingeniería, producto, soporte, ventas, operaciones e internos. No finjan que no funciona. Sí funciona, a veces sorprendentemente bien.

Pero no se conviertan en creyentes ciegos. La IA es potente, pero no es magia. Necesitan control, gobernanza, pruebas, observabilidad y una responsabilidad clara. De lo contrario, solo crearán caos más rápidamente.

La mentalidad adecuada no es ni «la IA lo reemplazará todo» ni «la IA está sobrevalorada». La mentalidad adecuada es «¿cómo puedo utilizar esto para hacer que mi organización sea diez veces más capaz?»

Sigue el contenido

Sigue las novedades de Abhishek Ranjan en LinkedIn. Y consulta su boletín Hacktivate.

¡Próximamente habrá más entrevistas con expertos en The CTO Club!