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

Tyrone Grandison ha ocupado muchos puestos directivos a nivel ejecutivo durante sus 35 años de carrera en el sector tecnológico y actualmente es el CTO 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 sector 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 compañías aseguradoras y muy poca tolerancia a los errores.

Comencé mi carrera como informático, mucho antes de que la IA se convirtiera en el tema de todas las conversaciones de los consejos de administración y de las ponencias principales de las conferencias. Con el paso de los años, mi trabajo me llevó de construir tecnología a liderar organizaciones mientras analizaba cómo la tecnología las estaba transformando. 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 sector tecnológico, he tenido el privilegio de observar cómo se introducían varias cosas como «la tecnología que lo cambiará todo». Y algunas de ellas realmente lo hicieron.

Cada gran cambio 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 dejado atrás una IA que 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 esa pregunta se está convirtiendo rápidamente en la menos interesante. Incluso en la pregunta equivocada.

Las preguntas mucho más importantes son: ¿Qué deberíamos permitirle hacer? ¿En qué aspectos 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 directivos y organizaciones para ayudarles a separar la información relevante de la considerable cantidad de ruido que rodea a la IA, comprender qué está cambiando realmente y convertir esa comprensión en estrategia, gobernanza, productos y resultados empresariales cuantificables.

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 se hacía cargo de 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. Por supuesto, utilizábamos automatización, 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 una canalización de desarrollo asistida 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 integración y entrega continuas (CI/CD) y de 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, afirma algo completamente erróneo con una seguridad 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 solución, pero no puede aprobar su propio trabajo ni tener una vía no controlada hacia producción.

Introdujimos puntos de aprobación humana explícitos para los cambios sensibles desde el punto de vista de la seguridad, la autenticación y la autorización, el manejo de los 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ó. Cuando la IA aumenta drásticamente la rapidez con la que puedes producir código, tu problema deja de ser la generación de código. Tu 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 funcionalidad y después escribir las pruebas unitarias obvias. Ahora también podemos pedir a la IA que genere casos de prueba adversarios. ¿Qué ocurre con una entrada con formato incorrecto? ¿Qué ocurre cuando una API devuelve una respuesta inesperada? ¿Qué ocurre en un límite de permisos? ¿Qué ocurre cuando el registro de un 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 a 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 cambia la IA el cuello de botella de 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 que se puede probar 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 ganancia de eficiencia menos glamurosa, pero más inmediata. La documentación de API, las notas de la 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 empezar 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 crearlo 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 incorrecto con rapidez.

Descubrimos que el factor limitante se desplaza hacia las etapas posteriores. Si puedo generar cinco veces más código, pero los humanos todavía tienen que comprenderlo, 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 de código.

Probablemente esa ha sido la lección más valiosa para mí. Ya no optimizo mi organización de ingeniería principalmente para determinar con qué rapidez podemos escribir software. La IA está convirtiendo rápidamente esa parte en un producto básico. Optimizo para determinar con qué rapidez 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

He adoptado una separación bastante consciente entre dos cosas: dónde tiene voz la IA y dónde tiene voto. En nuestra organización, la IA ahora tiene voz en casi todas las etapas de nuestro ciclo de vida tecnológico. No tiene voto en todas las decisiones.

Algunos ejemplos:

• Arquitectura: Usamos ChatGPT y Claude como interlocutores de debate arquitectónico. 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 las 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 tener en cuenta nuestra estrategia empresarial, las obligaciones regulatorias, la madurez operativa, la tolerancia al riesgo, los costes, 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. Usamos GitHub Copilot para generar código, refactorizarlo, documentarlo y crear pruebas unitarias. También usamos 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 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 usar 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 la seguridad, las decisiones relativas a la identidad y el acceso, el tratamiento de datos confidenciales y las excepciones. La inyección de instrucciones y la divulgación de información confidencial siguen siendo riesgos reconocidos en las aplicaciones basadas en LLM, por lo que conectar la IA a los sistemas empresariales requiere más controles, no menos.
• Respuesta ante incidentes: Este ámbito se sitúa en algún punto intermedio. La IA puede ingerir registros, correlacionar eventos, resumir miles de líneas de telemetría, proponer causas raíz probables y recomendar medidas de corrección. Eso puede comprimir drásticamente los primeros 30 minutos de un incidente. Pero si alguien quiere desactivar un servicio de producción, revertir una implementación crítica, 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í priorizaría estas 40 cosas y este es el motivo». Eso resulta increíblemente útil. Pero la IA no comprende 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 pocas consecuencias. La autoridad humana aumenta a medida que una acción resulta más difícil de revertir o conlleva un mayor impacto para los clientes, financiero, de seguridad, regulatorio 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 en el circuito». Supongamos que necesitamos añadir una nueva capacidad a un flujo de trabajo de un agente que obtiene información de clientes y de 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 de inmediato, utilizamos ChatGPT o Claude para analizar el requisito a fondo. Le proporcionamos la historia de usuario, los criterios de aceptación, las reglas de negocio relevantes, los contratos de API y las restricciones técnicas. Después le pedimos que identifique ambigüedades, casos extremos 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. Después viene la arquitectura y la descomposición de tareas. Utilizamos 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. Luego pasamos a la implementación. Utilizamos 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. Esa 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, en esencia, le decimos: «Genial. Ahora rómpelo». La IA ayuda a generar escenarios adversos y Copilot ayuda a convertirlos en pruebas unitarias y de integración automatizadas.
5. Después, la maquinaria determinista toma el control. 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, además de nuestras comprobaciones de calidad habituales. Un ingeniero humano revisa la solicitud de incorporación de cambios.
6. Después, desplegamos de forma incremental. El cambio pasa por desarrollo y preproducción antes de llegar a producción. Cuando corresponde, utilizamos indicadores de funcionalidad o patrones de despliegue 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 utilizamos para resumir registros, correlacionar patrones de error, analizar comportamientos inesperados y ayudar a los ingenieros a pasar de «algo va mal» a una causa raíz plausible mucho más rápido.

Cómo cambiar el comportamiento de ingeniería con 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 utilizar herramientas como GitHub Copilot, ChatGPT y Claude, abordé la implementación como 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.

Y así fue, pero no de manera uniforme ni siempre del modo que esperaba.

Lo primero que aprendí fue que tener acceso no equivale a adoptar una herramienta, y adoptarla no equivale a dominarla.

Dos ingenieros pueden tener exactamente la misma herramienta de IA y obtener resultados radicalmente distintos. Uno trata la IA como un autocompletado y ahorra unas pocas pulsaciones de teclas. Otro aprende a proporcionar contexto, descomponer problemas, cuestionar los resultados, generar pruebas, explorar alternativas y utilizar 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í tenéis una clase de dos horas sobre ingeniería de prompts», 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í tenéis una clase de dos horas sobre ingeniería de prompts», 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 con los desarrolladores, arquitectos, analistas y otros puestos técnicos. Creo que los CTO deben darle la vuelta a esa pregunta y formulárnosla a nosotros mismos.

Durante la mayor parte de mi carrera, el liderazgo tecnológico premiaba saber cosas que otras personas no sabían. La experiencia te daba capacidad para reconocer patrones. La especialización técnica te daba autoridad. Podías entrar en una sala y proporcionar una respuesta que a otra persona le habría llevado días encontrar.

Ahora puedo poner un sistema de IA increíblemente capaz en manos de todo el mundo. 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 ayuden mutuamente a mejorar.

Eso requiere humildad. A veces, la IA identificará un enfoque que yo no había considerado. Un ingeniero júnior con grandes conocimientos de 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 recibir eso con los brazos abiertos.

El CTO de la era de la IA no puede ser simplemente 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 confundáis 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 CEO preguntan por ella. Los empleados ya la están utilizando, tengáis o no una política al respecto. De repente, todos los proveedores han descubierto que su producto ha estado “impulsado por IA” todo este tiempo.

Es muy fácil volverse reactivo. Pero creo que el trabajo del CTO ahora mismo 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 únicamente en informes de analistas y demostraciones de proveedores. Utilizo herramientas como ChatGPT, Claude y GitHub Copilot porque necesito experiencia de primera mano sobre aquello en lo que 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 una capacidad limitada o estamos dejando frustrados a los clientes?”. Entonces puedo determinar si la IA realmente forma parte de la solución.
• Tercero, refuerza tus fundamentos. 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. Deja que las personas experimenten de forma decidida cuando las acciones sean reversibles y tengan pocas consecuencias. Aumenta la supervisión humana a medida que las decisiones comiencen a afectar a los datos de los clientes, el dinero, la seguridad, las obligaciones normativas o los sistemas de producción.
• Quinto, y este puede ser 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 agresivamente las tareas tediosas de las personas.

Creo que los CTO tienen ahora una oportunidad excepcional. No te limites a preguntar cómo puede la IA hacer 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 las empresas que realmente se transforman gracias a ella.

Mantente al tanto

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 Cultura que perdura.

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