En el contexto del Red Hat Summit: Connect 2026, realizado en Santiago, Víctor Cornejo, Chief Architect para Latinoamérica en Red Hat, abordó los desafíos de soberanía tecnológica que enfrentan las organizaciones ante las tensiones geopolíticas, las regulaciones sobre datos y la creciente adopción de inteligencia artificial.
La entrevista abarcó desde la dependencia de proveedores y las restricciones para desplegar inteligencia artificial hasta la protección de datos y las alternativas de infraestructura en Chile. Cornejo también explicó cómo Red Hat acompaña a las empresas que buscan recuperar autonomía tecnológica.
Admin
Soberanía tecnológica ante las condiciones del mercado y la regulación
Durante la conversación, el ejecutivo planteó que las decisiones sobre infraestructura y servicios tecnológicos están cada vez más condicionadas por factores externos, desde la disponibilidad de hardware hasta las restricciones de acceso a los modelos de inteligencia artificial más avanzados.
“Hay varios factores que están ocurriendo. Sabemos que existen temas económicos, globales, de costos, de disponibilidad de chips y de modelos, y de quién puede acceder a determinados modelos. Sabemos que Estados Unidos mantiene los modelos más avanzados, los modelos de frontera, con acceso restringido a un grupo selecto por lo riesgosos que son. Y esto va a ser así, va a ser constante”.
Estas condiciones también alcanzan al tratamiento de la información, especialmente cuando una organización utiliza servicios alojados en otros países. Cornejo advierte que las diferencias regulatorias pueden introducir restricciones que deben considerarse antes de adoptar una determinada arquitectura.
“Van a existir muchas variables externas que estarán influyendo e impactando en lo que hacemos con la tecnología. Desde la disponibilidad de hardware hasta las regulaciones que puedo tener localmente frente a la regulación del país donde está la casa central de la nube. Y cuál es la ley que manda sobre cómo debo proteger mis datos, si puedo tenerlos afuera o no puedo tenerlos afuera”.
Garantías de servicio y alternativas de salida
Para el representante de Red Hat, esta situación obliga a considerar la soberanía tecnológica como una capacidad que debe mantenerse durante toda la relación con un proveedor, debido a que las condiciones inicialmente acordadas pueden modificarse con el tiempo.
“Creo que las compañías hoy están a merced de este dinamismo político y tecnológico. Cuando nosotros hablamos de soberanía, lo importante es que las compañías puedan mantener ese control. Si hoy pueden tener un contrato con alguna nube que les da las garantías, pueden mantenerlo. Pero esas garantías pueden cambiar mañana según todo este movimiento”.
El arquitecto vincula esa capacidad de decisión con la posibilidad de trasladar aplicaciones y datos entre distintos entornos, sin quedar condicionado por una única infraestructura. Esta flexibilidad también forma parte de la estrategia que Red Hat plantea para el despliegue empresarial de IA.
“Mis garantías pueden cambiar desde los precios hasta la privacidad de los datos o la conectividad. La idea es que los clientes, en su elección tecnológica y en la nube que utilicen, puedan salir, tengan una alternativa de salida, puedan moverse e ir cambiando de una a otra. Nuestra postura es esa: multinube, multiplataforma y multimodelo”.
Dependencia de un único proveedor de inteligencia artificial
Cornejo extiende esta preocupación a las implementaciones de inteligencia artificial basadas completamente en los servicios de un mismo proveedor, donde las dependencias pueden abarcar tanto la infraestructura como los modelos y las herramientas utilizadas para desarrollar aplicaciones.
“Esto también aplica para el mundo de hoy. Cuando algunos implementan inteligencia artificial o agentes adoptando completamente el stack de un proveedor específico, se están vinculando directamente a ese proveedor. El salir de ahí y poder tener soberanía sobre su tecnología ya no está disponible de la misma manera”.
Desde esa perspectiva, la elección de una arquitectura tecnológica no se limita a sus características técnicas, porque también determina las alternativas disponibles para modificar servicios, negociar condiciones o cambiar de proveedor cuando las necesidades del negocio evolucionan.
“Realmente quedaron sujetos a lo que pueda ocurrir dentro de esa elección tecnológica, que más que tecnológica es una decisión de negocios”.
Francisco Carrasco M.
La libertad de elección tecnológica frente a la dependencia de proveedores
El concepto de control adquiere una dimensión más concreta cuando se examina la capacidad de una organización para modificar su infraestructura. El ejecutivo distingue entre los componentes que inevitablemente dependen de terceros y las decisiones arquitectónicas que una empresa puede mantener bajo su responsabilidad.
“Creo que tener el control no significa pretender controlar el procesador si uno no lo fabrica. Pero el control sigue estando ligado a la libertad de elección. Es lo que te mencionaba con las opciones de tecnología: si quiero elegir otra cosa y no puedo salir porque debo reconstruir todo, entonces no tengo realmente esa libertad”.
Admin
La posibilidad de cambiar de tecnología, por tanto, debe considerarse desde el diseño de los sistemas y no únicamente cuando aparece la necesidad de migrarlos. Cornejo relaciona esta capacidad con la planificación empresarial y la adaptación a nuevas condiciones operativas.
“Creo que es poder manejar hacia dónde quieres llevar tu compañía y, por ende, qué tecnología debe soportar el negocio de esa compañía. Es poder ir tomando las decisiones en el camino de manera dinámica. Eso es tener el control”.
En este escenario, la arquitectura adquiere un papel central porque determina las posibilidades de evolución de los sistemas. El Chief Architect de Red Hat considera que delegar completamente estas decisiones puede reducir la autonomía de una organización sobre sus propios procesos.
“Tener el control sobre el software que estás utilizando y no haber delegado tu arquitectura en un tercero. Porque la arquitectura hoy es el motor de la innovación de la compañía y de cómo se genera el negocio”.
Un proyecto de inteligencia artificial limitado por su propia arquitectura
Para explicar las consecuencias de una dependencia tecnológica, Cornejo presentó el caso de una organización centroamericana que comenzó a desarrollar aplicaciones de inteligencia artificial mediante servicios de proveedores de modelos de frontera. Las primeras pruebas funcionaron, pero las dificultades aparecieron al intentar avanzar hacia procesos que involucraban información real del negocio.
“Yo creo que se puede detectar prácticamente en un análisis post-mortem. Puedo mencionar el caso de un cliente de un país de Centroamérica que comenzó a implementar inteligencia artificial con servicios de algunos de estos proveedores de frontera. Empezó a implementar unos cuantos casos de uso para probar y funcionaron muy bien”.
El problema surgió cuando el proyecto requirió utilizar datos del cliente, momento en que intervinieron los equipos responsables de seguridad y cumplimiento. Las restricciones que identificaron no habían sido consideradas durante las etapas iniciales de experimentación.
“Pero cuando quiso ir al caso de uso que generaba un impacto real para el negocio, que daba valor al negocio y que implicaba datos del cliente, su equipo interno de seguridad y de control de datos le dijo que no podía mover esos datos fuera de las dependencias del país, por la legislación y muchas otras variables que la gente de tecnología no sabía y que la persona comercial tampoco conocía”.
Las restricciones que las pruebas iniciales no anticiparon
Según el relato del ejecutivo, la organización había dedicado recursos a conocer los servicios e implementar pruebas exitosas, aunque estas no permitieron anticipar las restricciones del entorno productivo. La tecnología seleccionada terminó siendo incompatible con las exigencias aplicables al tratamiento de los datos.
“Por lo cual, trabajaron mucho tiempo invirtiendo, entendiendo una tecnología e implementando algunos casos de uso mínimos, que fueron exitosos. Pero cuando llegaron al caso real, no podían implementarlo con la tecnología que escogieron porque no les permitía cumplir con la normativa interna de seguridad de la compañía ni con la legislación del país sobre privacidad de los datos”.
El caso refleja una diferencia entre validar las capacidades técnicas de una solución y comprobar si puede utilizarse bajo las condiciones reales de una empresa. Para Cornejo, ambas evaluaciones deben relacionarse con los objetivos comerciales y las obligaciones regulatorias desde el comienzo.
“Esos son ejemplos claros de cuando quiero hacer evolucionar a mi compañía hacia un lugar donde pueda generar más ingresos, cumpliendo con la normativa, y la tecnología realmente, por cómo está estructurado ese negocio, no es capaz de cumplir con esos requisitos mínimos y básicos”.
El representante de Red Hat atribuye parte de esta dificultad a la elección de una arquitectura propietaria que condicionaba las alternativas de implementación. En su interpretación, la dependencia del proveedor terminó limitando un proyecto que había demostrado viabilidad durante las pruebas iniciales.
“Como este cliente escogió una plataforma propietaria, tomó una elección por un camino que no le permitió innovar y generó un lock-in, o perdió soberanía sobre su negocio o su plataforma”.
Francisco Carrasco M.
Despliegue en la nube o en infraestructura propia
Como alternativa, Cornejo plantea utilizar tecnologías que permitan mantener una misma base de trabajo en distintos entornos de ejecución. De esta manera, las organizaciones podrían seleccionar la ubicación de cada aplicación considerando costos, latencia y restricciones legales.
“Una alternativa habría sido tomar una plataforma que le permitiera mantener la soberanía y que su equipo aprendiera esa tecnología. Para ciertos casos donde el costo lo justificara, podría implementar en la nube, y en otros donde la legislación no lo permitiera, o la latencia no lo permitiera, podría implementar on-premise con la misma tecnología”.
Esta capacidad de despliegue también supone aprovechar la infraestructura que una organización ya administra, sin exigir que todas sus aplicaciones dependan de servicios externos. El arquitecto considera que disponer de distintas alternativas es parte fundamental de la soberanía tecnológica.
“Una tecnología que te permite utilizar los centros de datos o servidores que tienes como infraestructura subyacente y que, dentro de tu elección, te permite ser soberano”.
Soberanía de datos y preparación ante la legislación chilena
Las restricciones descritas en el caso centroamericano también llevan la discusión hacia las normativas de protección de datos. En este ámbito, Cornejo señala que Red Hat toma como referencia las exigencias europeas para desarrollar capacidades de control y auditoría sobre sus tecnologías.
“Nosotros trabajamos mucho con Europa. Queremos que nuestras plataformas sean soberanas y tenemos muchas herramientas para aplicar controles en las auditorías que se realizan sobre ellas, además de muchas facilidades. Hablamos de soberanía de datos, soberanía de procesos y soberanía del código mismo que forma parte de las aplicaciones”.
El ejecutivo considera que la experiencia europea anticipa algunas de las exigencias que podrían adquirir mayor relevancia en otros mercados. Sin embargo, distingue entre los requisitos existentes en esa región y aquellos que actualmente corresponden al marco regulatorio chileno.
“Como compañía estamos siguiendo lo más evolucionado y avanzado en materia de soberanía, que es Europa. Muchas de estas cosas no van a aplicar en Chile, por lo menos todavía. Esperamos que Chile vaya evolucionando y tenga más normas que permitan y obliguen a las compañías a tomar decisiones mucho más responsables sobre su tecnología”.
Dónde ejecutar las aplicaciones y procesar los datos
Desde el punto de vista de Red Hat, la preparación tecnológica consiste en permitir que cada organización determine dónde ejecutar sus aplicaciones y procesar la información. Esto adquiere especial importancia en proyectos de inteligencia artificial que requieren acceder a datos empresariales.
“En cuanto a cómo ayudamos con la soberanía de los datos, esencialmente lo hacemos desde la plataforma. Llevamos a las empresas las tecnologías que requieren utilizar, particularmente la inteligencia artificial, que está directamente relacionada con los datos, hasta donde ellas quieran ubicarlas”.
La ubicación de esos recursos debe corresponder a las condiciones de acceso y protección exigidas a cada organización. Cornejo relaciona esta decisión con las garantías que puede entregar el proveedor encargado de alojar o procesar la información.
“Es decir, donde realmente tengan un proveedor que les entregue las garantías que la ley está exigiendo acerca del acceso a la información durante ese proceso”.
Responsabilidades internas para cumplir con la regulación
No obstante, el especialista diferencia la disponibilidad de herramientas tecnológicas del cumplimiento integral de una regulación. Aunque Red Hat puede contribuir a seleccionar infraestructura apropiada, la organización debe resolver también las obligaciones que corresponden a sus procedimientos internos.
“Estarían preparados para tomar la mejor elección de data center y de hardware, que les permita cumplir con la ley chilena. La ley chilena implica muchas cosas y algunas son procedimentales. Dentro de la organización tienen que crear ciertas estructuras de personas y unidades, además de mecanismos de respuesta a determinadas peticiones”.
En consecuencia, el apoyo tecnológico no reemplaza las responsabilidades administrativas y organizacionales relacionadas con la protección de los datos. El vocero sostiene que las empresas deben adaptar sus estructuras y procesos para responder a esas exigencias.
“Eso no lo entrega la tecnología. Tiene que hacerlo la compañía misma, cambiando su forma de trabajar. Nosotros somos el lado tecnológico que ellos necesitan para poder dar soporte a todo eso”.
Infraestructura disponible en Chile y criterios para adoptar inteligencia artificial
La discusión sobre cumplimiento y soberanía también comprende las alternativas de infraestructura disponibles en el mercado chileno. Cornejo reconoce avances entre los proveedores de nube y los operadores locales, aunque evita identificar a las empresas que considera mejor preparadas.
“Creo que los proveedores de nube que están presentes en Chile están siguiendo muy de cerca la legislación que tenemos. No voy a mencionar alguno específico, pero hay dos que están muy bien. También existen centros de datos locales y servicios locales que están muy bien”.
Francisco Carrasco M.
Como referencia, el ejecutivo menciona el caso de SONDA, presentado durante el Summit Connect en relación con su estrategia de virtualización. A su juicio, las organizaciones disponen de distintas alternativas locales, cuya selección debe responder a los requisitos específicos de cada proyecto.
“Habíamos explicado el caso de SONDA en virtualización durante este Summit Connect. Ellos también tienen centros de datos y existen varios proveedores locales más. Creo que Chile tiene muy buena infraestructura de centros de datos y de nubes, cada uno con sus propios controles. Lo importante es que las empresas evalúen lo que necesitan”.
Francisco Carrasco M.
Comprender la tecnología antes de invertir en IA
La disponibilidad de infraestructura, sin embargo, representa solo una parte de las decisiones necesarias para implementar nuevas tecnologías. Cornejo considera que las organizaciones también deben comprender sus capacidades antes de incorporarlas a los procesos empresariales.
“Creo que lo importante de todo es que entiendan la tecnología y los beneficios que tiene. Una vez que se entiende esto bien, ya no se termina implementando tecnología por moda”.
Esta observación adquiere relevancia en el contexto de la inteligencia artificial, donde algunas empresas comenzaron a utilizar servicios sin definir previamente los resultados que esperaban obtener. El representante de Red Hat cuestiona las decisiones impulsadas principalmente por tendencias del mercado.
“Lo hemos visto en muchos lugares. Varios escucharon que todas las empresas tenían que implementar inteligencia artificial porque alguna compañía de estudios mundiales lo dijo, y muchas organizaciones se apresuraron a implementar inteligencia artificial. Muchos gastaron dinero y muchos tienen cuentas enormes en ciertos proveedores de IA sin haber tenido un horizonte claro”.
Admin
Para el ejecutivo, el problema aparece cuando las iniciativas tecnológicas se desarrollan separadas de la planificación del negocio. En esos casos, las capacidades disponibles no necesariamente corresponden a las necesidades operativas o comerciales que justificaron la inversión.
“No fueron capaces de hacer una correspondencia entre hacia dónde querían llevar la evolución de su compañía y del negocio, con el entendimiento de las capacidades o el potencial que tenía la tecnología”.
La relación entre ambos elementos, añade Cornejo, debe resolverse antes de definir las herramientas y servicios que utilizará la organización. Su planteamiento consiste en comprender simultáneamente los objetivos empresariales y las posibilidades reales de la tecnología.
“Creo que ese divorcio de iniciativas es necesario tenerlo bajo control: entender la tecnología y saber hacia dónde quiero llevar mi negocio. Si tengo esas dos preguntas realmente resueltas, puedo utilizar mejor las capacidades que existen”.
El papel de Red Hat en la recuperación de la autonomía tecnológica
Frente a estas dificultades, Cornejo describe el trabajo de Red Hat desde dos dimensiones relacionadas: la selección de tecnologías y las capacidades internas de los equipos. El ejecutivo sostiene que la compañía busca entregar mecanismos de control sin imponer la utilización de un modelo específico de inteligencia artificial.
“Hay varios caminos. Uno es el entendimiento mismo de la tecnología y permitirles aprovechar lo mejor del mercado que existe. Porque nosotros no somos de decir ‘no uses ChatGPT, no uses…’. Puedes utilizar el modelo que prefieras, pero podemos entregarte la gobernanza del uso de estas plataformas y la seguridad sobre su utilización”.
Admin
Esta aproximación también considera la posibilidad de ejecutar modelos abiertos en entornos definidos por las propias organizaciones. Para el representante, disponer de esas alternativas permite mantener capacidad de negociación y reducir la dependencia de servicios determinados.
“También podemos entregarte el control si quieres ejecutar cualquier modelo open source en el entorno que tú quieras. Entonces, eso entrega poder sobre la tecnología y sobre la negociación existente en esa parte”.
El desarrollo de conocimientos internos constituye otro componente de esta estrategia, especialmente cuando los equipos conocen los procesos empresariales, pero necesitan adquirir competencias sobre nuevas herramientas. Cornejo menciona la capacitación y la consultoría como mecanismos para cubrir esas necesidades.
“Si el equipo de trabajo, la gente que ya existe y conoce muy bien el negocio, tiene brechas en el entendimiento de la tecnología, están los cursos de entrenamiento y los servicios de consultoría para poder cubrir esas brechas y realmente puedan avanzar. Ese es el gran punto: cómo toman las decisiones”.
Evaluación de soberanía y alternativas de migración
El acompañamiento también puede extenderse a organizaciones que ya enfrentan problemas de dependencia tecnológica. En estos casos, el Chief Architect explica que Red Hat dispone de un procedimiento de evaluación utilizado en Europa para determinar el grado de soberanía y orientar las decisiones posteriores.
“Nosotros tenemos internamente un assessment de soberanía que se utiliza mucho en Europa, que te responde qué tan soberano eres y te entrega este tipo de recomendaciones. Depende del caso”.
A partir de esa evaluación, la compañía puede identificar alternativas de migración o modernización que no necesariamente requieren utilizar exclusivamente sus propias tecnologías. Cornejo señala que este trabajo se ha realizado con organizaciones que habían quedado vinculadas a proveedores específicos.
“Hemos tenido varios clientes que se han visto amarrados con un lock-in en alguna plataforma, no necesariamente hoy, sino años atrás. Hemos realizado evaluaciones, adquirido un mayor entendimiento y después les ofrecemos un camino que puede incluir tecnología Red Hat o tecnología que no es de Red Hat, pero que trabaja en conjunto con nosotros”.
Estas evaluaciones pueden involucrar a otras empresas tecnológicas y operadores de infraestructura, dependiendo de las características de cada organización. El ejecutivo presenta este enfoque como una actividad de consultoría que considera distintas alternativas de implementación.
“Con lo cual, es una visión de consultoría integral que podemos entregar en conjunto con algunos partners, alianzas o algunos otros proveedores de centros de datos, dependiendo del caso”.
La recuperación de autonomía tecnológica, por tanto, no corresponde necesariamente a reemplazar un proveedor por otro, sino a revisar las condiciones que originaron la dependencia. Cornejo señala que estas situaciones también forman parte de las consultas que recibe Red Hat.
“Pero sí, si alguien se siente secuestrado por algún proveedor, puede ponerse en contacto con nosotros. Esas también son consultas que nos hacen, porque ¿qué pasa cuando yo me encuentro en esta situación? ¿Cómo lo resuelvo?”.
Columnas al director
Un modelo comercial basado en soporte y estándares abiertos
El representante vincula esta postura con el modelo comercial de Red Hat, basado en tecnologías abiertas y contratos de soporte. Según explica, el objetivo es mantener la relación con los clientes mediante la continuidad del servicio, en lugar de impedir que adopten otras alternativas tecnológicas.
“Sí, porque nosotros desde el inicio creemos en la apertura, creemos en el open source y ese es el principio. No buscamos el lock-in de nadie y nosotros no vendemos licencias. Lo que buscamos es la renovación de un soporte”.
Cornejo cierra su planteamiento diferenciando la permanencia de un cliente por la calidad del soporte de aquella que depende de restricciones técnicas para abandonar una tecnología. En su visión, los estándares abiertos permiten cambiar de proveedor sin perder necesariamente la continuidad tecnológica.
“Nuestro negocio es que nuestros clientes sigan confiando en nosotros y quieran estar con nosotros. Porque si quieren salir de tecnología Red Hat, es tecnología abierta. Van a encontrar los mismos estándares en otras plataformas, con un servicio distinto o diferente, y nuestro foco es aportar un soporte de excelencia”.
