El sector TIC está formado por trabajo que se deja dividir fácilmente en pasos repetibles y trabajo que precisamente no lo permite. Escribir código, probar, documentar, clasificar tickets, evaluar monitorización, desplegar configuraciones: muchas de estas tareas tienen una estructura fija y un criterio de evaluación claro. Junto a eso está el trabajo que gira en torno a decisiones arquitectónicas, contexto del cliente, consideraciones de seguridad y la decisión de si un sistema pasa o no a producción. Esa distinción determina dónde la IA ya asume tareas hoy, dónde sigue siendo necesario el supervisión, y dónde el trabajo humano sigue siendo el núcleo del asunto.
Las circunstancias que dirigen el resultado no son uniformes. Un equipo que trabaja con una base de código bien documentada y estándares de prueba claros puede transferir tareas con más facilidad que un equipo que funciona con conocimiento tribal y acuerdos verbales. Una organización con una estructura de revisión fija puede integrar la supervisión sobre la salida de la IA en un proceso existente; una organización sin esa estructura primero debe construirla antes de que la transferencia sea responsable.
En partes del sector el cambio ya es visible. Las sugerencias de código, la generación de pruebas y las actualizaciones de documentación se producen en algunos equipos en gran medida mediante IA, con un desarrollador que aprueba o rechaza según la funcionalidad y la legibilidad. En otros equipos exactamente el mismo trabajo aún se hace completamente a mano, no porque allí la situación sea fundamentalmente distinta, sino porque faltan las condiciones: sin acceso a las herramientas adecuadas, sin criterios de calidad establecidos, sin tiempo reservado para reconstruir el proceso.
Esa diferencia entre empresas rara vez reside en la tecnología misma. Reside en la preparación: si la organización tiene los datos y la documentación en orden, si hay un derecho de decisión asignado a quién evalúa la salida de la IA, si se ha liberado capacidad para configurar el nuevo proceso antes de desmantelar el antiguo. Donde faltan esas condiciones, una ambición se queda en el papel, incluso cuando la tecnología ya está disponible.
Una ambición como "la IA apoya a nuestros desarrolladores" suena inequívoca, pero en la práctica exige una serie de capacidades que no están presentes de forma automática: un entorno de pruebas que pueda validar código generado por IA, un proceso de revisión que no se ralentice por el volumen adicional, y evaluadores que sepan cuándo rechazar una propuesta de IA. Sin esas capacidades, la ambición sigue siendo una intención sin ejecución.
Esa es precisamente la razón por la que las mismas palabras pueden significar cosas distintas dentro de un equipo directivo. El CTO piensa en pipelines automatizados, el director operativo en menos horas liberadas para soporte, el responsable de RR. HH. en una redefinición de roles. Ninguna de estas interpretaciones es incorrecta, pero sin una prueba compartida la ambición sigue siendo optativa. Cómo se traduce una visión en algo medible, y no en tres suposiciones sueltas, se describe en cómo se hace medible una visión.
El sector TIC no es único en su lucha con este cambio, aunque los puntos de fricción difieren. En los servicios financieros la pregunta se plantea de otra manera, porque allí la supervisión y la rendición de cuentas tienen un papel mayor; lo que ocurre allí se describe en qué ambiciones de IA se plantean en los servicios financieros. En la construcción, el trabajo físico es un factor fijo que limita la asunción por la IA de forma distinta a como lo hace en TIC, tal como se explica en qué ambiciones de IA se plantean en la construcción. Y en el sector de la limpieza se trata sobre todo de planificación y control de calidad en lugar de producción de código, desarrollado en qué ambiciones de IA se plantean en el sector de la limpieza. El patrón es siempre el mismo: la ambición se vuelve concreta solo en el momento en que queda claro qué capacidades faltan.
Un equipo directivo que decide que la IA debe asumir "la mayor parte del ciclo de revisión" formula con ello una ambición que no se puede realizar en un trimestre. Eso no es una objeción a la ambición en sí, sino una señal para fasearla: qué capacidad debe establecerse primero, cuál después, y en qué punto la organización está por primera vez en condiciones de evaluar si funciona. Cómo puede verse ese faseo se describe en cómo se fasea una ambición demasiado grande para un año.
Sobre las decisiones de personal que puedan derivarse de tal faseo, no nos pronunciamos: qué trabajo deja de existir o se redistribuye por parte de un empleador cae bajo sus propios requisitos legales y su propia decisión. Lo que describimos es qué trabajo se deja transferir, en parte o por completo, y bajo qué condiciones.
La pregunta subyacente no es si las ambiciones de IA en el sector TIC son reales, sino si esta empresa en concreto, con esta base de código, este equipo y estos procesos, está lista para llevarlas a cabo. Qué trabajo en esta empresa puede transferirse realmente a la IA, tarea por tarea, se responde con el escáner de trabajo de FTE TO AI.
Quien primero quiera una impresión, sin compromiso, puede hacer la comprobación de preparación gratuita: ocho preguntas breves, una por dimensión, con una imagen de dónde la organización está más avanzada y dónde menos. La prueba de ambición completa, con las cuatro capas y las cinco puertas de confianza, está en construcción.
Vertel wat u wilt bereiken, dan kijken we samen wat daarvoor moet staan.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.