Por  Insight UK / 10 Aug 2026 / Temas: Modern workplace
Hay un momento que muchos responsables tecnológicos reconocerán: su proyecto de entrega se cierra, el nuevo sistema entra en funcionamiento y su socio pasa al siguiente proyecto. A partir de ese momento, la organización se hace responsable de algo que no diseñó pensando plenamente en su operación a largo plazo: marcos de gobernanza que siempre iban a resolverse más adelante, equipos que trabajan con el sistema a diario pero que no participaron en su construcción, y documentación que describe cómo se creó, en lugar de cómo mantenerlo en funcionamiento.
Este tipo de colaboraciones limitadas a la entrega siguen siendo habituales en los proyectos tecnológicos. En algunos tipos de software, el vacío que dejan puede resultar manejable. En el caso de la IA, no suele serlo: un sistema de IA en producción conlleva un conjunto adicional de requisitos continuos, y no siempre se manifiestan hasta que las cosas empiezan a ir mal.
El espacio que separa un sistema que ya se ha lanzado de una capacidad de IA que funciona de forma fiable y dentro de las normas. Las organizaciones que consiguen cerrarla suelen compartir un mismo enfoque: trabajan con socios que ya pensaban en el mes doce desde el primer día.
Poner en marcha el sistema de IA es solo el primer paso. El éxito de una prueba de concepto rara vez garantiza el rendimiento en el mundo real.
A partir del 2 de agosto de 2026, las obligaciones de alto riesgo de la Ley de IA de la UE serán plenamente exigibles para las empresas que operen en la UE: evaluaciones de conformidad, procesos documentados, supervisión continua y una responsabilidad clara sobre las decisiones automatizadas. «Estar en marcha» ya no es la meta final, y para las organizaciones cuyas colaboraciones en materia de IA se diseñaron en torno a un punto final de entrega, eso supone una brecha real que hay que cerrar. Además, un acuerdo provisional ha establecido un calendario más amplio con fechas que se derivan de esta. Haz clic en las fechas clave a continuación.
Descubre los plazos de cumplimiento clave y los hitos de aplicación de la normativa.
Los mecanismos de aplicación entran en vigor para los sistemas de IA de alto riesgo. Las organizaciones deben garantizar que sus marcos de gestión de riesgos, sus políticas de gobierno de datos y su documentación técnica cumplan con los estándares regulatorios.
Las obligaciones de alto riesgo son plenamente exigibles para las empresas que operan en la UE. Las organizaciones deben establecer evaluaciones de conformidad, procesos documentados, supervisión continua y una responsabilidad clara sobre las decisiones automatizadas.
Pruebas previas a la comercialización, evaluaciones de riesgo y certificación regulatoria obligatorias para verificar la seguridad del sistema y el cumplimiento de los estándares antes de su despliegue.
El acuerdo provisional restablece la obligación de los proveedores de registrar los sistemas de IA en la base de datos de la UE para sistemas de alto riesgo, en los casos en que consideren que sus sistemas están exentos de esa clasificación.
Restablece el criterio de estricta necesidad para el tratamiento de categorías especiales de datos personales con el fin de garantizar la detección y corrección de sesgos.
Aclara las competencias de la Oficina de la IA en la supervisión de los sistemas de IA basados en modelos de IA de propósito general cuando el modelo y el sistema son desarrollados por el mismo proveedor, y enumera las excepciones en las que las autoridades nacionales conservan su competencia, incluidas las fuerzas de seguridad, la gestión de fronteras, las autoridades judiciales y las entidades financieras.
La brecha de entrega aparece con tanta frecuencia porque la mayoría de las colaboraciones en materia de IA se definen en torno a una sola fase de un recorrido de tres fases. Estos alcances parciales generan tres modos de fallo claramente diferenciados en el éxito a largo plazo de los proyectos de IA.
La consultora elabora una hoja de ruta coherente, un caso de negocio bien argumentado y una visión realmente convincente de lo que el producto podría llegar a ser. Pero después, la realidad de la ingeniería pasa a ser problema de otro. Las preguntas que determinan si un sistema de IA realmente funciona en producción (cómo se comporta el modelo con datos reales en lugar de con conjuntos de prueba limpios, cómo son los costes de inferencia a gran escala, cómo se conecta con los sistemas que la empresa ya utiliza) necesitan a alguien presente que las entienda desde el principio. Las brechas entre la estrategia y la realidad de la ingeniería pueden causar problemas en cualquier proyecto tecnológico, pero en la IA suelen aparecer más tarde y cuestan más de corregir.
La integración con los sistemas heredados es donde las colaboraciones de entrega dejan más a menudo trabajo sin terminar. Las conexiones más difíciles (entre las capacidades modernas de IA y los sistemas más antiguos que gestionan otras funciones) suelen resolverse justo lo suficiente para poder lanzar, dejando el trabajo más profundo para más adelante. Una vez que la colaboración se cierra, ese trabajo pendiente pasa a ser responsabilidad de la organización.
Contar con una capacidad integral de extremo a extremo significa que el mismo socio se hace cargo de todas estas fases: una estrategia basada en la realidad de la ingeniería, una ingeniería diseñada para funcionar desde el primer día y una estrategia operativa integrada desde el principio para mantener los sistemas en funcionamiento, en cumplimiento normativo y en constante mejora, además, de forma crucial, un socio que ayude a identificar casos de uso que generen un valor de negocio genuino, no solo aquellos que sean técnicamente viables.
Un proveedor educativo líder mundial, presente en casi 200 países y que ofrece contenido digital, evaluaciones y soluciones de aprendizaje impulsadas por tecnología a escala global, se puso en contacto con nosotros. La división de ingeniería de esta organización planteó una pregunta que la mayoría de las organizaciones no se plantean lo bastante pronto: no solo si la IA iba a funcionar, sino si sus propios equipos estarían preparados para gestionarla de forma segura, someterla a una gobernanza adecuada y seguir mejorándola por sí mismos.
Una encuesta inicial entre los ingenieros reveló algo que las cifras generales de adopción de la IA suelen ocultar. La mayoría del equipo ya utilizaba herramientas de IA con regularidad, así que las cifras parecían saludables; pero un uso regular no implica necesariamente un uso eficaz o seguro, un patrón que se repite en muchas organizaciones.
Al profundizar en cómo se utilizaban realmente las herramientas, se descubrió que la evaluación estructurada de los resultados de la IA era inconsistente, y que las técnicas más sofisticadas, que suelen generar las mejoras más significativas, se utilizaban muy poco.
Aún más relevante fue descubrir qué era lo que frenaba a las personas: la preocupación por la seguridad y el cumplimiento normativo fue, con diferencia, la barrera más citada, mencionada por ingenieros de todos los roles y funciones. Las personas que no tenían claro qué datos era seguro compartir con la IA, o bien evitaban por completo ciertas herramientas, o bien tomaban sus propias decisiones sin ningún marco coherente que las guiara. El problema no era la falta de cuidado, sino la ausencia de estándares, orientación sobre herramientas y confianza. Desplegar más tecnología no iba a solucionarlo.
El programa se propuso construir lo que a los equipos les faltaba: la infraestructura para un uso seguro y eficaz de la IA. Esto se logró mediante una combinación de:
En lugar de dejar que esos estándares se diluyeran una vez finalizada la colaboración, se creó una red interna de referentes, en la que los profesionales con más experiencia asumieron una responsabilidad visible sobre los estándares emergentes y desempeñaron un papel formativo en la fase de acompañamiento.
Los resultados superaron con creces lo que se había planteado como objetivo inicial:
La cifra relativa a la gobernanza es la más relevante en el contexto del plazo del 2 de agosto. Al final del programa, el personal senior era capaz de nombrar controles específicos: configuraciones confirmadas de licencias empresariales, fragmentos de código anonimizados para información sensible, divulgación en las PR como práctica estándar. Un equipo detectó a tiempo una herramienta con capacidad de escritura que estaba sobrescribiendo el contenido de un ticket, antes de que se convirtiera en un incidente real: el tipo de conciencia práctica del riesgo que no surge de un documento de políticas, sino que se construye a lo largo de meses.
«Lee cada línea. La IA genera código que parece plausible pero que puede estar probando algo completamente distinto. Si no puedes hacer que la prueba falle con una entrada incorrecta, no está probando nada.»
La prueba más contundente de que esta capacidad realmente se transfirió fue lo que ocurrió tras finalizar el programa. El equipo de control de calidad (el grupo que se había autoevaluado de forma más conservadora al principio) acabó desarrollando dos agentes centrados en problemas concretos de su propio proceso de entrega. Ninguno de los dos fue creado por Insight AI. Los construyeron los propios ingenieros del equipo, utilizando una capacidad que ahora pertenece a esa organización.
Este programa demuestra cómo es construir una capacidad duradera a nivel organizativo: preparar a las personas que gestionan un sistema de IA para utilizarlo de forma segura y someterlo a una buena gobernanza. La misma pregunta se aplica a nivel de ingeniería: si el propio sistema se construyó para poder operarse, adaptarse y gobernarse con el tiempo, o simplemente para lanzarse.
Nosotros mismos pusimos en práctica estos principios al crear AURA, una plataforma de conocimiento impulsada por IA diseñada para resolver un problema interno real: convertir el trabajo de proyectos ya finalizados en casos de éxito orientados al cliente era un proceso lento, manual y que a menudo hacía que el contenido no estuviera listo cuando una oportunidad de venta lo necesitaba. Con AURA, nuestros equipos de ventas tienen acceso a evidencias relevantes mientras trabajan en una operación, y pueden crear narrativas en varios idiomas que muestran a los clientes nuestra experiencia, lo que se traduce en un beneficio comercial directo. Pero construirla también nos dio la oportunidad de aplicar a nuestros propios sistemas los mismos principios de ingeniería que aplicaríamos en un proyecto para un cliente.
Selecciona un pilar para descubrir la base estructural
Las decisiones que determinan si se puede confiar en un sistema con el paso del tiempo rara vez son visibles en una demo. Aparecen meses después: cuando los datos que gestiona el sistema se vuelven más sensibles, cuando el uso escala, cuando el marco regulatorio se endurece. Por eso, en lugar de tratar la gobernanza y el cumplimiento normativo como algo que se añade una vez el sistema ya está en marcha, los integramos desde el principio.
Ninguna de estas decisiones cambia lo que el sistema hace el primer día, pero sí determinan si AURA puede operarse de forma responsable a escala, adaptarse a medida que cambian los requisitos y someterse a una gobernanza en condiciones cada vez más exigentes, incluidas las obligaciones que la Ley de AI de la UE convierte ahora en continuas en lugar de puntuales.
AURA sigue en funcionamiento, ha continuado evolucionando y se rige por los mismos fundamentos que establecimos desde el principio. La plataforma se ha desarrollado ahora hasta poder crear narrativas más amplias, temáticas o centradas en un sector concreto, a partir de grupos de casos de éxito relevantes; algo que no habría sido posible construir sobre un sistema que no hubiera estado diseñado para crecer.
Las obligaciones de alto riesgo de la Ley de IA de la UE no pueden satisfacerse con una aprobación puntual. Exigen una conformidad continua: documentación permanente, supervisión, control humano de las decisiones automatizadas y estructuras de responsabilidad claras que puedan demostrarse, no solo describirse. Para las organizaciones cuyas colaboraciones en materia de IA terminan en la entrega, cumplir con ese estándar es un reto operativo para el que no estarán preparadas.
Lo que ilustra el programa de capacidad en IA del proveedor educativo es cómo se ve, en la práctica, la preparación regulatoria: el personal senior capaz de nombrar controles específicos y aplicarlos en contexto, el equipo que detectó un riesgo de gobernanza antes de que se convirtiera en un incidente de producción, y los estándares, materiales de gobernanza y red de referentes que siguen rigiendo el uso de la IA en la organización a medida que la tecnología continúa evolucionando.
Ese tipo de base operativa es, cada vez más, también una ventaja comercial. Donde la mayoría de las organizaciones encuentran difícil la complejidad regulatoria, las que la gestionan bien obtienen una ventaja:
de las organizaciones señala la complejidad regulatoria (RGPD, DORA, la Ley de IA) como uno de sus mayores retos estratégicos
de los clientes exige ahora una prueba de cumplimiento normativo como parte del proceso de compra
de las organizaciones ha utilizado sus credenciales de soberanía para ganar o mantener negocio — The Digital Sovereignty Trilemma
Las organizaciones que puedan demostrar un cumplimiento normativo continuo, y no solo señalar una aprobación puntual de entrega, serán las que mantengan una ventaja a medida que las obligaciones sigan aumentando.
Tanto el programa de capacidad en IA de nuestro proveedor educativo como nuestro proyecto AURA muestran cómo es construir pensando en el largo plazo en la práctica, aunque partiendo de enfoques distintos. El programa de capacidad en IA construyó una capacidad interna (los estándares, la gobernanza y la confianza necesarios para seguir mejorando) de modo que, cuando Insight AI se retiró, la organización pudiera continuar por su cuenta. AURA se diseñó desde el principio para perdurar, con las decisiones que determinan la operatividad a largo plazo tomadas durante la construcción y no aplazadas para más adelante. Ambos casos se reducen a lo mismo: quién piensa más allá de la entrega antes de que esta comience.
Para la mayoría de las organizaciones, esa pregunta se responde mucho antes de que el sistema entre en funcionamiento. Depende de si el socio que lo construyó pensaba en las operaciones desde el principio: si la estrategia tuvo en cuenta la realidad de la ingeniería, si la ingeniería se diseñó pensando en lo que habría que operar, y si la responsabilidad continua formaba parte de la colaboración desde el principio, en lugar de dejarse como una conversación para más adelante.
Esa continuidad en la responsabilidad (a lo largo de la estrategia, la ingeniería y el trabajo continuo de mantener un sistema en funcionamiento) es lo que realmente significa un enfoque integral de extremo a extremo.