El director de tecnología afirma que la IA necesita un nuevo modelo de gobernanza

Tyrone Grandison ha desempeñado numerosos cargos de nivel C en sus 35 años de carrera en el ámbito tecnológico y actualmente es el director de tecnología de Cornerstone Assurance Corporation. También es el autor de La revolución de la IA y La cultura que perdura.

Hablamos con Tyrone para conocer cómo la IA está cambiando la gobernanza en las organizaciones tecnológicas. Esto es lo que nos contó.

35 años en el ámbito tecnológico

Lidero una organización tecnológica ágil que presta apoyo a una empresa en crecimiento de seguros y servicios financieros llamada Cornerstone Assurance Corporation. Lo que hace que el puesto sea especialmente interesante es que estamos construyendo una pila tecnológica moderna mientras operamos en un sector con importantes requisitos normativos, datos financieros sensibles, integraciones complejas con aseguradoras y muy poca tolerancia a los errores.

Comencé mi carrera como científico informático, mucho antes de que la IA se convirtiera en el tema de conversación de todas las reuniones de los consejos de administración y de todas las ponencias principales de las conferencias. Con el paso de los años, mi trabajo me llevó de desarrollar tecnología a liderar organizaciones mientras afrontaban las consecuencias de la tecnología. He ejercido como director de Inteligencia Artificial, director de Tecnología, director de Información y director adjunto de Datos. He trabajado en la administración pública, el ámbito académico, empresas emergentes, consultoría, organizaciones sin ánimo de lucro y grandes empresas.

Después de 35 años en el ámbito tecnológico, he tenido el privilegio de ver cómo se presentaban varias cosas como «la tecnología que lo cambiará todo». Y algunas de ellas realmente lo hicieron.

Cada gran transformación obliga a los líderes a tomar decisiones antes de disponer de información perfecta. Pone a prueba los modelos de negocio, los modelos operativos, la cultura, el talento, la gobernanza y, en ocasiones, nuestra comprensión de cuál se supone que es nuestro propio trabajo. La IA está haciendo todo eso a la vez.

Pero lo que hace que este momento me resulte especialmente fascinante es que hemos superado la fase en la que la IA simplemente nos ayudaba a analizar información. Ahora contamos con sistemas capaces de generar, razonar, planificar, crear, escribir código, utilizar herramientas y, cada vez más, actuar. Eso cambia fundamentalmente la conversación sobre liderazgo.

La pregunta solía ser: «¿Qué puede hacer la IA?»

Creo que esta se está convirtiendo rápidamente en la pregunta menos interesante. Incluso en la pregunta equivocada.

Las preguntas mucho más importantes son: ¿Qué deberíamos permitirle hacer? ¿En qué ámbitos sigue siendo esencial el criterio humano? ¿Cómo rediseñamos las organizaciones cuando el conocimiento se vuelve abundante? ¿Y cómo aprovechamos el extraordinario potencial de esta tecnología sin crear riesgos que no comprendemos o sistemas que no podemos gobernar?

Ahí es donde se centra actualmente mi trabajo. Trabajo con ejecutivos y organizaciones para ayudarles a separar la información relevante del considerable ruido que rodea a la IA, comprender qué está cambiando realmente y convertir esa comprensión en estrategia, gobernanza, productos y resultados empresariales medibles.

Cómo transforma la IA los ciclos de vida del desarrollo de software

Uno de los mayores cambios que introduje en Cornerstone Assurance Corporation fue rediseñar nuestro ciclo de vida del desarrollo de software partiendo de la premisa de que la IA escribirá un porcentaje significativo de nuestro código.

Antes de ese cambio, seguíamos un flujo de trabajo de ingeniería bastante tradicional. Un desarrollador asumía un requisito, diseñaba la solución, escribía el código, creaba las pruebas, enviaba una solicitud de incorporación de cambios y otro ingeniero la revisaba. Utilizábamos automatización, por supuesto, pero los humanos seguían realizando la mayor parte del trabajo cognitivo, desde los requisitos hasta la implementación.

La IA cambió por completo la economía de ese modelo.

Por eso introdujimos un flujo de desarrollo asistido por IA que utiliza GitHub Copilot para la generación y refactorización de código, ChatGPT y Claude para la exploración arquitectónica dirigida por IA, la descomposición de requisitos, la depuración y la generación de casos de prueba, mientras que nuestras herramientas habituales de CI/CD y seguridad proporcionan los controles deterministas en torno al trabajo generado por la IA.

Por qué el código generado por IA requiere un nuevo modelo de gobernanza

Pero el cambio importante no fue decir: «Bueno, ahora todos tenéis Copilot». Cambiamos el modelo de gobernanza.

Controles de aprobación

Ahora tratamos el código generado por IA casi como si lo hubiera enviado un ingeniero júnior muy rápido que nunca duerme, ha leído una cantidad absurda de documentación y, en ocasiones, dice algo completamente erróneo con una confianza extraordinaria.

Eso significa que la IA puede generar código, pruebas unitarias, contratos de API, documentación, consultas de bases de datos, definiciones de infraestructura y propuestas de corrección, pero no puede aprobar su propio trabajo ni tener una vía sin control hacia producción.

Introdujimos puntos de aprobación humana explícitos para los cambios sensibles a la seguridad, la autenticación y la autorización, la gestión de datos de clientes y financieros, las integraciones externas y la infraestructura de producción.

Pruebas automatizadas

También ampliamos las pruebas automatizadas y la revisión de código porque el cuello de botella cambió de lugar. Cuando la IA aumenta drásticamente la rapidez con la que se puede producir código, el problema deja de ser la generación de código. El problema pasa a ser demostrar que el código merece ejecutarse.

Un ejemplo sencillo es la creación de pruebas. Antes, un ingeniero podía implementar una función y después escribir las pruebas unitarias obvias. Ahora también podemos pedirle a la IA que genere casos de prueba adversariales. ¿Qué ocurre con una entrada con un formato incorrecto? ¿Qué ocurre cuando una API devuelve una respuesta inesperada? ¿Qué ocurre en un límite de permisos? ¿Qué ocurre cuando un registro de cliente contiene datos incompletos?

Eso proporciona al ingeniero humano una tarea diferente. En lugar de dedicar todo su tiempo a producir artefactos, dedica más tiempo a cuestionar las suposiciones y validar el comportamiento del código.

Gobernanza de la IA

También cambiamos la forma en que gobernamos la propia IA. Registramos la actividad asistida por IA cuando corresponde, mantenemos la información confidencial de los clientes fuera de las herramientas de IA para consumidores, controlamos qué modelos y servicios pueden acceder a los datos empresariales y separamos la experimentación del acceso a producción. En los seguros y los servicios financieros, “el modelo pensó que era una buena idea” nunca constituirá una estrategia de gobernanza.

Cómo la IA desplaza el cuello de botella de la ingeniería

El mayor resultado que he observado al integrar la IA en nuestros flujos de trabajo de ingeniería es la velocidad, pero siempre añado un asterisco a esa respuesta porque la velocidad en la dirección equivocada no es productividad.

La IA ha acortado drásticamente nuestro ciclo de desarrollo. Estamos viendo que trabajos que antes llevaban varios días a un desarrollador pasan de los requisitos a una implementación comprobable en cuestión de horas. En concreto, para la creación de prototipos, estimaría que hemos reducido el tiempo del ciclo entre un 50 y un 70 por ciento, aproximadamente.

Y la documentación probablemente ha producido la mejora de eficiencia menos glamurosa, pero más inmediata. La documentación de API, las notas de versión, la documentación de pruebas, las explicaciones del código y los primeros borradores de las especificaciones técnicas ya no tienen que comenzar con un cursor parpadeante. La IA produce el primer 70 u 80 por ciento, y mi equipo dedica su tiempo a corregir y mejorar en lugar de crear todo desde cero.

Pero hay una desventaja, y creo que los líderes tecnológicos deben hablar más de ella: la IA hace que resulte increíblemente barato producir código defectuoso con rapidez.

Descubrimos que el factor limitante se desplaza hacia las fases posteriores. Si puedo generar cinco veces más código, pero los humanos todavía tienen que entenderlo, revisarlo, probarlo, protegerlo, implementarlo, supervisarlo y mantenerlo, no necesariamente he aumentado el rendimiento del sistema. Puede que simplemente haya creado un atasco en la revisión del código.

Probablemente esa ha sido la lección más valiosa para mí. Ya no optimizo mi organización de ingeniería principalmente en función de la rapidez con la que podemos escribir software. La IA está convirtiendo rápidamente esa parte en una mercancía. Optimizo en función de la rapidez con la que podemos demostrar que el software merece ejecutarse en producción. Esa es una organización de ingeniería muy diferente.

Dónde tiene voz la IA frente a dónde tiene voto

Me he vuelto bastante meticuloso a la hora de separar dos cosas: cuándo la IA tiene voz y cuándo la IA tiene voto. En nuestra organización, la IA ya tiene voz en casi todas las etapas del ciclo de vida de nuestra tecnología. No tiene voto en todas las decisiones.

Algunos ejemplos:

• Arquitectura: Utilizamos ChatGPT y Claude como interlocutores para poner a prueba nuestras decisiones arquitectónicas. Si estamos diseñando un servicio nuevo, puedo proporcionar al modelo nuestros requisitos, restricciones, interfaces existentes, límites de seguridad, volumen de transacciones previsto y escenarios de fallo. Le pediré que proponga varias arquitecturas, identifique ventajas y desventajas, cuestione nuestras suposiciones e incluso argumente en contra de su propia recomendación. Lo que no haré es preguntar: «¿Qué arquitectura deberíamos utilizar?» y después construir lo que devuelva. La decisión final sobre la arquitectura sigue correspondiendo a las personas, porque la arquitectura implica un contexto que va mucho más allá de la optimización técnica. Tengo que considerar nuestra estrategia empresarial, las obligaciones normativas, la madurez operativa, la tolerancia al riesgo, el coste, la deuda técnica y lo que mi equipo puede mantener realmente a las 2:00 de la madrugada.
• Código: Aquí damos a la IA bastante más margen de actuación. Utilizamos GitHub Copilot para generar código, refactorizarlo, documentarlo y crear pruebas unitarias. También utilizamos ChatGPT y Claude para solucionar defectos, explorar enfoques de implementación y generar casos de prueba adversarios. La IA puede escribir una primera implementación increíblemente rápido. Un ingeniero humano sigue siendo responsable de la solicitud de incorporación de cambios y aprueba lo que finalmente se integra.
• Pruebas: Probablemente este ámbito es el que más se ha desplazado hacia la IA. Me encanta utilizar la IA para preguntar: «¿Cómo romperías esto?». Podemos encontrar casos que un desarrollador que acaba de pasar dos días creando la funcionalidad podría pasar por alto inconscientemente. La IA se convierte en un adversario muy económico y extremadamente persistente.
• Seguridad: Aquí invierto deliberadamente la ecuación. La IA nos ayuda a identificar vulnerabilidades, inspeccionar patrones de código, modelar amenazas y generar escenarios de ataque, pero, como he dicho, las personas conservan la autoridad sobre la aceptación de seguridad, las decisiones de identidad y acceso, el tratamiento de datos sensibles y las excepciones. La inyección de instrucciones y la divulgación de información sensible siguen siendo riesgos reconocidos en las aplicaciones basadas en modelos de lenguaje de gran tamaño, por lo que conectar la IA a los sistemas empresariales requiere más controles, no menos.
• Respuesta ante incidentes: Este ámbito se encuentra en algún punto intermedio. La IA puede ingerir registros, correlacionar eventos, resumir miles de líneas de telemetría, proponer posibles causas raíz y recomendar medidas de corrección. Esto puede reducir drásticamente los primeros 30 minutos de un incidente. Pero si alguien quiere deshabilitar un servicio de producción, revertir un despliegue crítico, cambiar una política de seguridad o realizar una acción que afecte a los clientes, esa decisión la toma una persona.
• Priorización del trabajo pendiente: Aquí aplico la misma regla. La IA puede analizar problemas de soporte, esfuerzo de ingeniería, dependencias, uso del producto y objetivos empresariales, y decir: «Así es como priorizaría estas 40 cosas y este es el motivo». Esto resulta increíblemente útil. Pero la IA no entiende nuestra estrategia mejor que nosotros. Los responsables de producto y tecnología toman la decisión final sobre la priorización.

Por tanto, mi regla es bastante sencilla: la IA obtiene más autonomía cuando la acción es reversible, observable, comprobable y tiene consecuencias reducidas. La autoridad humana aumenta a medida que una acción resulta más difícil de revertir o tiene un mayor impacto para los clientes, financiero, de seguridad, normativo o reputacional.

Un flujo de trabajo de ingeniería del mundo real

Aquí tienes un ejemplo de un flujo de trabajo de «requisito a producción con la IA dentro del proceso». Supongamos que necesitamos añadir una nueva capacidad a un flujo de trabajo de agentes que obtiene información del cliente y de las políticas, aplica un conjunto de reglas empresariales y recomienda la siguiente acción adecuada:

1. Todo comienza con el requisito. En lugar de que un ingeniero reciba un ticket redactado de forma imprecisa y empiece a programar inmediatamente, usamos ChatGPT o Claude para analizar exhaustivamente el requisito. Les proporcionamos la historia de usuario, los criterios de aceptación, las reglas de negocio pertinentes, los contratos de API y las restricciones técnicas. Después les pedimos que identifiquen ambigüedades, casos límite que falten, dependencias, problemas de seguridad y preguntas que debamos responder antes de que nadie escriba código. Parece sencillo, pero detecta de forma temprana una cantidad sorprendente de confusiones costosas.
2. A continuación viene la arquitectura y la descomposición de tareas. Usamos Claude y ChatGPT para explorar opciones de implementación y dividir los requisitos en componentes. El modelo puede identificar un cambio en la API, un cambio en el modelo de datos, una dependencia de integración, requisitos de autorización, telemetría y los casos de prueba necesarios. También le pedimos que argumente en contra de la arquitectura que propone. Un ingeniero humano toma la decisión arquitectónica. La IA proporciona opciones. Nosotros asumimos las consecuencias.
3. Después pasamos a la implementación. Usamos GitHub Copilot dentro del entorno de desarrollo para generar código repetitivo, implementar funciones bien definidas, refactorizar código, crear clientes de API, explicar secciones desconocidas de la base de código y generar documentación. El ingeniero pasa de escribir cada línea a dirigir, revisar y perfeccionar la implementación. Esta distinción es importante. No quiero que los desarrolladores se conviertan en operadores de autocompletado muy caros. Quiero que piensen en el sistema.
4. Después proporcionamos a ChatGPT o Claude el requisito y la implementación y, básicamente, decimos: «Genial. Ahora rómpelo». La IA ayuda a generar escenarios adversarios, y Copilot ayuda a convertirlos en pruebas unitarias y de integración automatizadas.
5. Después toma el control la maquinaria determinista. La solicitud de incorporación de cambios entra en nuestra canalización de CI/CD. Ejecutamos pruebas automatizadas, análisis estático, análisis de dependencias y vulnerabilidades, y nuestros controles de calidad habituales. Un ingeniero humano revisa la solicitud de incorporación de cambios.
6. Después realizamos el despliegue de forma incremental. El cambio pasa por desarrollo y preproducción antes de llegar a producción. Cuando corresponde, usamos indicadores de funcionalidades o patrones de lanzamiento controlado para limitar la exposición, observar el comportamiento y revertir los cambios rápidamente.
7. Y el trabajo de la IA tampoco termina ahí. Una vez que la funcionalidad está en ejecución, la IA se convierte en un asistente de observabilidad. La usamos para resumir registros, correlacionar patrones de errores, analizar comportamientos inesperados y ayudar a los ingenieros a pasar de «algo no funciona» a una causa raíz plausible mucho más rápido.

Cómo cambiar el comportamiento de ingeniería con la IA

Ojalá hubiera entendido antes que proporcionar herramientas de IA a los ingenieros es fácil. Cambiar el comportamiento de ingeniería es la parte difícil.

Cuando empezamos a usar herramientas como GitHub Copilot, ChatGPT y Claude, abordé la implementación como lo hacen muchos líderes tecnológicos. Proporcionar herramientas potentes a ingenieros con talento, establecer algunas medidas de protección sensatas y esperar a que aumentara la productividad.

Aumentó, pero no de forma uniforme ni siempre de la manera que esperaba.

Lo primero que aprendí fue que el acceso no equivale a la adopción, y la adopción no equivale al dominio.

Dos ingenieros pueden tener exactamente la misma herramienta de IA y obtener resultados radicalmente distintos. Uno trata la IA como un autocompletado y se ahorra unas cuantas pulsaciones de teclas. Otro aprende a proporcionar contexto, descomponer problemas, cuestionar los resultados, generar pruebas, explorar alternativas y usar el modelo como interlocutor técnico. La diferencia de productividad entre esas dos personas puede llegar a ser enorme.

Habría invertido mucho antes en alfabetización en IA y en formas de trabajo. No en «aquí tienes una clase de dos horas sobre ingeniería de instrucciones», sino en ejemplos prácticos basados en nuestro trabajo real de ingeniería.

Comentarios de Tyrone

Habría invertido mucho antes en alfabetización en IA y en formas de trabajo. No en «aquí tienes una clase de dos horas sobre ingeniería de instrucciones», sino en ejemplos prácticos basados en nuestro trabajo real de ingeniería.

Cómo la IA está transformando el liderazgo tecnológico

Pasamos mucho tiempo preguntándonos qué hará la IA a los desarrolladores, arquitectos, analistas y otros profesionales técnicos. Creo que los CTO deben darle la vuelta a esa pregunta y dirigirla hacia nosotros mismos.

Durante la mayor parte de mi carrera, el liderazgo tecnológico premiaba saber cosas que los demás no sabían. La experiencia te daba capacidad para reconocer patrones. La pericia técnica te otorgaba autoridad. Podías entrar en una sala y dar una respuesta que a otra persona quizá le habría llevado días encontrar.

Ahora puedo poner un sistema de IA increíblemente capaz en manos de todos. Eso cambia el liderazgo.

Ya no creo que mi valor como CTO provenga de tener las respuestas. Proviene de hacer mejores preguntas, aportar contexto, tomar decisiones de compromiso, ejercer el criterio y crear un entorno en el que los seres humanos y las máquinas se hagan mejores mutuamente.

Eso requiere humildad. A veces la IA identificará un enfoque que yo no había considerado. Un ingeniero júnior con grandes habilidades para usar la IA puede cuestionar una suposición que alguien con 25 años de experiencia considera obvia. Creo que los grandes líderes tecnológicos deben aceptar eso.

El CTO de la era de la IA no puede limitarse a ser la persona técnicamente más inteligente de la sala. Tenemos que convertirnos en las personas que diseñan la sala. ¿Quién tiene voz? ¿Qué puede decidir la IA? ¿Dónde sigue siendo esencial el criterio humano? ¿Cómo sabemos cuándo nos equivocamos?

Esa es la transformación del liderazgo.

Por qué los CTO deben ser cautelosos con las mejoras de eficiencia

Mi principal consejo para los CTO en este momento es el siguiente: no confundas avanzar rápido con progresar.

Existe una enorme presión sobre los líderes tecnológicos para que «hagan algo con la IA». Los consejos de administración preguntan por ella. Los directores ejecutivos preguntan por ella. Los empleados ya la están utilizando, tengas o no una política al respecto. De repente, todos los proveedores han descubierto que su producto siempre ha estado «impulsado por IA».

Es muy fácil volverse reactivo. Pero creo que el trabajo del CTO en este momento consiste en aportar claridad en medio de todo ese ruido.

• Primero, utiliza la tecnología tú mismo. Y me refiero a utilizarla de verdad. No construyas tu estrategia de IA basándote exclusivamente en informes de analistas y demostraciones de proveedores. Utilizo herramientas como ChatGPT, Claude y GitHub Copilot porque necesito experiencia de primera mano sobre en qué son extraordinarias, dónde fallan y a qué velocidad se están desplazando esos límites. No puedes liderar eficazmente una transición tecnológica que solo experimentas a través de PowerPoint.
• Segundo, empieza por las limitaciones del negocio, no por las capacidades de la IA. Me interesa mucho menos preguntar «¿Dónde podemos utilizar la IA generativa?» que preguntar «¿Dónde somos lentos, caros, incoherentes, tenemos limitaciones de capacidad o estamos dejando frustrados a los clientes?». Después puedo determinar si la IA realmente debe formar parte de la solución.
• Tercero, corrige tus cimientos. La IA no rescatará unos datos deficientes, unas API débiles, una observabilidad deficiente, una documentación inexistente o unas prácticas de ingeniería disfuncionales. A menudo los amplificará. La IA actúa como un amplificador de la organización y del sistema técnico subyacentes.
• Cuarto, diseña la gobernanza en torno a las consecuencias, no al miedo. No quiero una política de IA de 47 páginas que, en la práctica, diga «Por favor, no hagas nada interesante». Quiero controles proporcionales al riesgo. Permite que la gente experimente de forma decidida cuando las acciones sean reversibles y tengan pocas consecuencias. Aumenta la supervisión humana cuando las decisiones empiecen a afectar a los datos de los clientes, al dinero, la seguridad, las obligaciones normativas o los sistemas en producción.
• Quinto, y quizá este sea el punto más importante, rediseña el trabajo en lugar de limitarte a añadir IA al trabajo. Si mi proceso de desarrollo tiene doce pasos y la IA hace que el paso cuatro sea un 70 por ciento más rápido, no he transformado la ingeniería. He acelerado el paso cuatro.
• Y por último, protege el criterio humano mientras eliminas de forma decidida las tareas tediosas para las personas.

Creo que los CTO tienen ahora una oportunidad excepcional. No te limites a preguntar cómo hace la IA más eficiente tu organización actual. Pregunta qué organización construirías si empezaras hoy. Esa es la pregunta más incómoda. También es la que separará a las empresas que simplemente utilizan la IA de aquellas que realmente se transforman gracias a ella.

Sigue la actualidad

Puedes seguir el trabajo de Tyrone Grandison en LinkedIn y en su sitio web personal. También puedes consultar sus libros, La revolución de la IA y Una cultura que perdura.

¡Habrá más entrevistas con expertos en The CTO Club!