Por qué la gobernanza robusta de IA protege los márgenes empresariales

Introducción

La adopción empresarial de la inteligencia artificial ya no es sólo un proyecto experimental: muchas organizaciones están integrando modelos directamente en seguridad, generación de código, decisiones automatizadas y procesos comerciales críticos. Según Rob Thomas, SVP y CCO de IBM, el ciclo típico de maduración del software va de producto independiente a plataforma y luego a infraestructura fundacional —y cuando una tecnología alcanza ese último estadio, las reglas del juego cambian.

Este artículo resume las ideas centrales del análisis de IBM y contextualiza su relevancia práctica para empresas, especialmente en América Latina, donde la combinación de restricciones de datos, necesidades de latencia y presión sobre márgenes vuelve urgente una gobernanza de IA sólida.

De producto a infraestructura: un cambio de paradigma

En la etapa inicial, un producto cerrado y controlado por un único proveedor puede ofrecer rapidez de desarrollo y una experiencia de usuario coherente. Ese enfoque concentra el valor económico y suele ser suficiente al comenzar.

Sin embargo, cuando el software pasa a ser una capa de infraestructura —en la que dependen múltiples sistemas operativos, mercados y marcos institucionales—, la apertura deja de ser una opción ideológica y se convierte en una necesidad práctica. IBM subraya que, a escala de infraestructura, la principal preocupación deja de ser únicamente qué pueden hacer los modelos de machine learning y pasa a ser cómo se construyen, gobiernan, inspeccionan y mejoran de manera sostenida.

Riesgos de modelos cerrados para la operación y los márgenes

El avance reciente de modelos como Claude Mythos de Anthropic ilustra por qué los equipos de seguridad y tecnología deben replantear sus estrategias. Anthropic reportó que esta versión limitada del modelo puede descubrir y explotar vulnerabilidades de software a un nivel comparable al de pocos expertos humanos. En respuesta, lanzaron Project Glasswing, una iniciativa controlada que prioriza poner esas capacidades en manos de defensores de red.

Desde la perspectiva de IBM, esta capacidad plantea una exposición estructural: concentrar el conocimiento y el control en manos de pocos proveedores puede crear riesgos operativos severos. Algunos problemas concretos que emergen al usar modelos cerrados y muy controlados son:

• Falta de visibilidad interna: cuando la lógica del modelo está opaca, los equipos no pueden diagnosticar si un comportamiento anómalo proviene del pipeline de recuperación de información (retrieval-augmented generation) o de los pesos base del modelo.
• Fricción en la integración: conectar modelos propietarios con bases de vector empresariales o lagos de datos sensibles genera cuellos de botella para resolver errores y validar resultados.
• Latencia y cumplimiento: las arquitecturas on-premises combinadas con modelos en la nube restringidos introducen latencia y obligan a sanitizar datos. En entornos con políticas estrictas de privacidad, eso significa mayor carga operativa.
• Costos de cómputo y sobredimensionamiento: el uso continuo de APIs cerradas puede disparar costos y forzar acuerdos de aprovisionamiento caro para garantizar disponibilidad, erosionando los márgenes que la IA debía mejorar.

Estos efectos no son sólo técnicos: impactan directamente la velocidad operativa, la experiencia del cliente y la rentabilidad.

Por qué el open-source es vital para la resiliencia operativa

IBM defiende que, a escala de infraestructura, la seguridad y resiliencia mejoran con la inspección rigurosa externa más que con el secreto absoluto. Esta es la lección histórica del software open-source: no elimina el riesgo, pero transforma la forma en que se gestiona.

Una base abierta permite que investigadores, desarrolladores corporativos y defensores de la seguridad examinen la arquitectura, identifiquen debilidades, prueben supuestos y fortalezcan el software en condiciones reales. En operaciones de ciberseguridad, la visibilidad suele ser prerrequisito para la resiliencia: tecnologías ampliamente examinadas tienden a ser más robustas porque más ojos las desafían y mejoran.

Además, la apertura no necesariamente destruye la ventaja competitiva. IBM plantea que cuando las capas fundacionales se vuelven comunes, el valor comercial se desplaza hacia la implementación compleja, la orquestación de sistemas, la fiabilidad continua, las mecánicas de confianza y el conocimiento sectorial. En otras palabras, la competencia se eleva hacia capas superiores del stack.

Implicaciones y recomendaciones para empresas en América Latina

Las conclusiones tienen implicaciones prácticas para tomadores de decisión en la región:

• Priorizar gobernanza y visibilidad: definir quién audita modelos, cómo se validan outputs críticos y qué métricas de confiabilidad se monitorizan debe ser parte del proyecto desde la etapa de diseño.
• Evaluar trade-offs entre proveedores cerrados y abiertas: un proveedor cerrado puede acelerar despliegues, pero con costos de integración, cumplimiento y operación que pueden afectar el margen. Las soluciones abiertas pueden requerir mayor inversión inicial en integraciones, pero facilitarán inspección, optimización de costos y personalización a mediano plazo.
• Diseñar arquitecturas híbridas conscientes: combinar modelos on-prem con componentes cloud requiere políticas claras de anonimización, flujos de datos y pruebas de latencia. En muchos casos, arquitecturas que permitan ejecutar modelos localmente para datos sensibles y delegar cargas no críticas al cloud son más sostenibles.
• Incorporar capacidades internas de revisión: formar equipos que entiendan cómo auditar modelos (tanto técnicos como de riesgo de negocio) reduce dependencia de terceros y acelera la respuesta ante incidentes.
• Considerar impacto en costos: medir el costo real de consumir modelos como servicio (cuentas de API, latencia, necesidad de over-provisioning) y comparar con alternativas que permitan optimizar consumo de cómputo.

Para empresas latinoamericanas, además, hay que considerar limitaciones específicas: conectividad variable, regulaciones de datos emergentes y sensibilidad al costo. Todo esto aumenta la relevancia de arquitecturas que ofrezcan control local y transparencia.

Conclusión

A medida que la IA se transforma en infraestructura crítica, la gobernanza deja de ser un tema accesorio y pasa a ser central para proteger márgenes y continuidad operacional. La experiencia que comparte IBM, reforzada por desarrollos como el Claude Mythos de Anthropic y su Project Glasswing, muestra que la apertura y la inspección continua no son sólo buenas prácticas técnicas: son herramientas para reducir riesgos, disminuir costos operativos y redistribuir el valor hacia la capacidad de implementar, orquestar y mantener sistemas confiables.

En la práctica, las organizaciones que inviertan en políticas de gobernanza claras, visibilidad técnica y capacidades internas de auditoría estarán mejor posicionadas para capturar el beneficio económico de la IA sin sacrificar seguridad ni sostenibilidad financiera.